Configure and Extend Launch

7 Configure and Extend Launch

Extension Framework

Use this topic to understand the extensibility framework for configuring and extending the Launch application.

Schema-based extension framework is based on the TMF630 extension specification. Application composer is used to build that framework and inheritance is achieved through TMF630 extension patterns. The @type and @basetype fields in the data model is used to establish the inheritance hierarchy.

Use the Application Composer to create or build the additional extensible fields required to support the extensions. See About Application Composer.

To work with schema-based extensions, it's important to understand the three key fields that TMF uses to support and model the extension pattern of entities. All the top-level resources have the three following key fields:

@type: Denotes the resource schema, which defines the resource. You must create and upload the YML file in this name.
@basetype: Denotes the parent resource type.
@schemaLocation: Denotes the URL from which a YML formatted file representing the schema can be read.

Schema-based extension is based on adding new attributes to the existing schema directly. Schema-based extension allows two different ways of extending an resource:

Adding a simple attribute of type string, number, boolean, date, and so on to the top-level product offer resource.
Adding a complex attribute of type JSON object or JSON array to the top-level product offer resource.

For an example of the ProductOffering resource represented with specific attributes in ProductOfferingOracle.yml, see the schema-based extension file in REST API Reference for Launch Cloud Service.

As part of Launch Cloud Service, TMF resources like product offering have been extended to ProductOfferingOracle and similar extensions exist for other resources as well to enable you to do after market extensions in a similar way. An example of an after market extension for a service provider like Vision Inc will be to add a top-level attribute to ProductOfferingOracle schema and name it as ProductOfferingVision.yml.

Customized Roles for Users

You can create or modify child objects that you created as part of the extension framework by adding the role ORA_CRM_EXTN_ROLE to the user.

Extension Types

Use this topic to understand some of the types of extensions that you can do within the Launch application.

You do these extensions using Application Composer and you will need to refer the Application Composer guide for details on some of the aspects covered in this topic. See About Application Composer .

Here's a quick start to using Application Composer to create extensions:

Access Application Composer at runtime by using the Navigator menu, and selecting Application Composer under the Configuration category.
To make most application changes, you should work in a sandbox. In fact, many functions in Application Composer aren't available until you enter into an active sandbox. You must be a user with Custom Object Administration role to be able to create sandboxes.
You use sandboxes to make application changes and test them without impacting other users in the environment. Wherever possible, make changes to the application in a sandbox rather than making direct changes in the mainline environment.
Make object or schema changes in Application Composer and publish changes.

Note:

After the extensions are published, they can't be reverted.
Make changes to schema files and upload them to UCM via API.
Start using the extended attributes via the APIs.

Simple Attribute Extension

To understand how you can implement a simple attribute extension, let's take the example of a service provider like Supremo. To perform an extension, Supremo would add a top-level attribute to the ProductOfferingOracle schema and name it ProductOfferingSupremo.yml.

Go to Application Composer.
Select CRM Cloud from the Application drop-down list.
Click Standard Objects on the Objects Explorer.

All the standard objects shipped by the application are displayed including that of other Oracle Fusion applications.

Note:
There are two sections, Custom and Standard. Standard fields are the base fields based on TMF resource specifications and there's no access to edit the standard fields. See the Resource Details table for a list of the TMF 620 Resources, Oracle Fusion applications standard objects that support extension along with their YML schema names. For the example, Product Offering standard object is used.
Click Product Offering > Fields.
On the Fields page, Custom section, click Create.
On the Select Field Type dialog box, select a corresponding type, for example, Text and click OK.

The data type supported in Application Composer includes strings, numbers, boolean, date, datetime, and choice list (enums). In this example, the simple attribute Supremo is a text field.
On the Create Text Field dialog box, fill in the following:
1. Display Name: Specify the Display name as Supremo. The display name is the view name of the attribute in Application Composer.
2. Display Label: Select a Display Label, for example, Supremo. The Display Label field retains the name of the attribute used for the Application Composer object.
3. API Name: It's auto generated with respect to the DisplayName, by trimming the white space, for example, Supremo. This name must be used in the service payload. If you change it, the same must be used in service payload.
4. Description: Provide a description of the attribute.
5. Constraints:
  1. Required: Selecting this makes the attribute mandatory with the service payload. It's suggested to not enable this option for a custom attribute because this affects the base object. If you prefer to make an attribute or object as required, you can restrict in schema.
  2. Updatable: This is checked by default. Disabling this will fail the update operation.
  3. Searchable: This is related to Application Composer REST service and isn't used in this scenario.
  4. Indexed: This is related to Application Composer REST service and isn't used in this scenario.
  5. Minimum Length: A text field specific constraint used to define the minimum length supported. By default the value is set to 0.
  6. Maximum Length: A text field specific constraint used to define the maximum length supported. The default length is 80.
6. Default Value: Fixed Value: You can define a static value for the payload, for a boolean field.
Add lookups or enums for the custom attribute:
1. Click Fields within the corresponding standard object.
2. On the Fields page, Custom section, click Create.
3. On the Select Field Type dialog box, select a corresponding type. You must select Choice List and click OK.
4. Enter the following information:
  1. Display Name: This field is mandatory. The display name is visible for a user in Application Composer.
  2. API Name: This gets generated automatically based on the display name and is used in the payload.
  3. Required: Selecting this makes the attribute mandatory with the service payload. It's suggested to not enable this option for a custom attribute because this affects the base object. If you prefer to make an attribute or object as required, you can restrict in schema.
  4. Updatable: This is checked by default. Disabling this will fail the update operation.
  5. Searchable: This is related to Application Composer REST service and isn't used in this scenario.
5. Click Add in the Lookup Type section and add the following information, if the extended field is a lookup type:
  
  Note:
  You need not perform the following steps if it's a string with a free form text.
  1. Meaning: This field is mandatory as it serves as the display name.
  2. Lookup type: Code to identify lookup. Unique code to identify the list.
  3. Description: Add description about the lookup.
  4. To add values to lookup, click Actions> Create.
  5. Meaning: This field is mandatory as it serves as the display name.
  6. Lookup type: Code to identify lookup value.
  7. Description: Add description about the lookup.
  8. Enabled: Select to either enable or disable a particular value usage.
  9. Display Sequence: Specify the order of display.
Click Save and ensure that the new field, Supremo, is added to the Custom Field section.
Go to sandbox and publish the sandbox.

Note:
You can perform testing only after publishing the sandbox.

After the sandbox is published, create the schema file with the simple attribute that you just created and refer to the ProductOfferingOracle schema.

Note:

The extension will be available in the instance at this point.

title: ProductOfferingSupremo
type: object
description: 'It's designed to model flexible interface definition in order to provide maximal reuse for existing rating algorithms.'
allOf:
  - $ref: 'ProductOfferingOracle.yml'
  - properties:
      Supremo:
        type: string
        description: Name of partner

Save it as ProductOfferingSupremo.yml and upload to custom folder using schema endpoint.

After the schema is uploaded, use the REST API endpoints to POST and GET data. Here's a sample payload and the steps to go about testing:

Publish the sandbox changes.
Upload the custom schema created with extension attributes to custom folder using schema upload endpoint.
Use the resource endpoint to trigger extension. For example, https://<hostname>/crmRestApi/atcProductCatalog/11.13.18.05/tmf-api/productCatalogManagement/v4/productOffering.

{
    "id": "SUP_PS_WS_ROAM_105",
    "name": "Wireless Roaming PS 105",
    "description": "Product Specification for Wireless Roaming",
    "version": "1.0",
    "lifecycleStatus": "In design",
    "@type": "ProductOfferingSupremo",
    "@baseType": "ProductOfferingOracle",
    "project": {
        "name": "P_16_9_2020_11_55_15",
        "id": "P_16_9_2020_11_55_15"
    },
    "validFor": {
        "startDateTime": "2020-09-14T00:00:00.000Z"
    },
    "Supremo": "Amazefit-v"
}

Complex Attribute Extension: Object and Array

You can perform an aftermarket extension using complex type extension by adding array or object to the existing resources. Application Composer supports only child object as array type, which is the default. There's no place in Application Composer where you can specify the type of child that you want to extend, for example, array or object. This can be achieved with custom schema. During schema creation you must restrict the type of child to be created in Application Composer as array or object. Here's how you can do it.

Object Type Extension

For example, let's introduce a complex object called PartnerDetailsOffering within the product offering resource. The PartnerDetails is an object which contains two text fields PartnerName and PartnerCode. You must begin by enabling Application Composer through sandboxes. You must be an user with Custom Object Administration role to be able to create sandboxes. For more information on how to create and activate sandboxes, see Create and Activate Sandboxes.

Go to Application Composer.
Click Standard Objects.
Click Product Offering.
On the ProductOffering: Overview page, click Create Child Object.
On the Create Child Object dialog box, enter the following information:
1. Display Name: This name is used to display the object in Application Composer. As naming standard display name carries proper white spaces, the object name is displayed as Partner Details. Based on the display name, the rest of the fields get auto populated.
2. API Name: This name is used in service payload. The API name gets generated based on the display name, by trimming the white space, and is displayed as PartnerDetails. You can't modify the API name after creating it. Also, you must provide the same name as object name in the payload.
Click Save to create the child object. The same now appears within the ProductOffering object in the Standard Objects section.
Expand the Partner Details child object and click Fields. There will be two sections similar to simple attribute, which are Custom and Standard.
To create PartnerName as well as PartnerCode, click Create in the Custom section.
On the Select Field Type dialog box, select a corresponding type, for this example, Text and click OK.
On the Create Text Field dialog box, fill in the following:
1. Display Name: Specify the display name. All other fields will be auto generated.
2. Display Label: Select a Display Label. This field retains the name of the attribute used for the Application Composer object. However, it isn't used in the payload or on the UI.
3. API Name: It's auto generated with respect to the DisplayName, by trimming the white space. This name must be used in the service payload. If you change it, the same must be used in service payload.
4. Description: Provide a description of the attribute
5. Constraints:
  1. Required: Selecting this makes the attribute mandatory with the service payload. It's suggested to not enable this option for a custom attribute because this affects the base object. If you prefer to make an attribute or object as required, you can restrict in schema.
  2. Updatable: This is checked by default. Disabling this will fail the update operation.
  3. Searchable: This is related to Application Composer REST service and isn't used in this scenario.
  4. Indexed: This is related to Application Composer REST service and isn't used in this scenario.
  5. Minimum Length: A text field specific constraint used to define the minimum length supported. By default the value is set to 0.
  6. Maximum Length: A text field specific constraint used to define the maximum length supported. The default length is 80.
6. Default Value: Fixed Value: You can define a static value for the payload, for a boolean field.
7. Add lookups or enums for the custom attribute:
  1. Click Fields within the corresponding standard object.
  2. On the Fields page, Custom section, click Create.
  3. On the Select Field Type dialog box, select a corresponding type. You must select Choice List and click OK.
  4. Enter the following information:
    1. Display Name: This field is mandatory. The display name is visible for a user in Application Composer.
    2. API Name: This gets generated automatically based on the display name and is used in the payload.
    3. Required: Selecting this makes the attribute mandatory with the service payload. It's suggested to not enable this option for a custom attribute because this affects the base object. If you prefer to make an attribute or object as required, you can restrict in schema.
    4. Updatable: This is checked by default. Disabling this will fail the update operation.
    5. Searchable: This is related to Application Composer REST service and isn't used in this scenario.
  5. Click Add in the Lookup Type section and add the following information:
    1. Meaning: This field is mandatory as it serves as the display name.
    2. Lookup type: Code to identify lookup. Unique code to identify the list.
    3. Description: Add description about the lookup.
    4. To add values to lookup, click Actions> Create.
    5. Meaning: This field is mandatory as it serves as the display name.
    6. Lookup type: Code to identify lookup value.
    7. Description: Add description about the lookup.
    8. Enabled: Select to either enable or disable a particular value usage.
    9. Display Sequence: Specify the order of display.
8. Click Save and verify the changes.
9. Go to sandbox and publish the sandbox.

Here's the custom schema for type object.

title: PartnerDetailsOffering
type: object
description: 'It's designed to model flexible interface definition in order to provide maximal reuse for existing rating algorithms.'
allOf:
  - $ref: 'ProductOfferingOracle.yml'
  - properties:
      PartnerDetails:
        type: object
        description: Partner details Reference
        properties:
          PartnerName:
            type: string
            description: partner name details
          PartnerCode:
            type: string
            description: partner code details

The type of child created is referred to as object so the extension will only support the format of objects. The schema is saved as PartnerDetailsOffering.yml and uploaded to the custom folder using schema endpoint as described in Upload schema section. For more information on uploading schema, see the section in this topic on uploading schema via Launch schema endpoint.

After the schema is uploaded, use the REST API endpoints to POST and GET data. Here's a sample payload and the steps to go about testing:

Publish the sandbox changes and verify the changes.
Upload the custom schema created with extension attributes to custom folder using schema upload endpoint.
Use the resource endpoint to trigger extension. For example, https://<hostname>/crmRestApi/atcProductCatalog/11.13.18.05/tmf-api/productCatalogManagement/v4/productOffering.

To test the scenario, the following payload can be used, with @type as PartnerDetailsOffering to trigger the extension.

{
    "id": "SUP_PS_WS_ROAM_203",
    "name": "Partner Details Spec 203",
    "description": "Product Specification for Wireless Roaming",
    "version": "1.0",
    "lifecycleStatus": "In design",
    "@type": "PartnerDetailsOffering",
    "@baseType": "ProductOfferingOracle",
    "project": {
        "name": "P_16_9_2020_11_55_15",
        "id": "P_16_9_2020_11_55_15"
    },
    "validFor": {
        "startDateTime": "2020-09-14T00:00:00.000Z"
    },
    "PartnerDetails": {
        "PartnerName": "Supremo",
        "PartnerCode": "AT-01"
    }
}

Array Type Extension

The workflow for an array type extension is similar to that of a custom object type. Here the child object is treated as an array type. For the example, an array ConsumerList containing fields, ConsumerName, and ConsumerCode are used. Application Composer can be enabled only through sandboxes. You must be a user with Custom Object Administration role to be able to create sandboxes. For more information on how to create and activate sandboxes, see Create and Activate Sandboxes.

Go to Application Composer.
Click Standard Objects.
Click Product Offering.
On the ProductOffering: Overview page, click Create Child Object.
On the Create Child Object dialog box, enter the following information:
1. Display Name: This name is used to display the object in Application Composer. As naming standard display name carries proper white spaces, the object name is displayed as Consumer List. Based on the display name, the rest of the fields get auto populated.
2. API Name: This name is used in service payload. The API name gets generated based on the display name, by trimming the white space, and is displayed as ConsumerList. You can't modify the API name after creating it. Also, you must provide the same name as object name in the payload.
Click Save. The same now appears within the ProductOffering object in the Standard Objects section.
Expand the Consumer List child object and click Fields. There will be two sections similar to simple attribute, which are Custom and Standard.
To create ConsumerName as well as ConsumerCode, click Create in the Custom section.
On the Select Field Type dialog box, select a corresponding type, and click OK.
On the Create Field dialog box, fill in the following:
1. Display Label: Select a Display Label. This field retains the name of the attribute used for the Application Composer object. However, it isn't used in the payload or on the UI.
2. API Name: It's auto generated with respect to the DisplayName, by trimming the white space. This name must be used in the service payload. If you change it, the same must be used in service payload.
3. Description: Provide a description of the attribute
4. Constraints:
  1. Required: Selecting this makes the attribute mandatory with the service payload. It's suggested to not enable this option for a custom attribute because this affects the base object. If you prefer to make an attribute or object as required, you can restrict in schema.
  2. Updatable: This is checked by default. Disabling this will fail the update operation.
  3. Searchable: This is related to Application Composer REST service and isn't used in this scenario.
  4. Indexed: This is related to Application Composer REST service and isn't used in this scenario.
  5. Minimum Length: A text field specific constraint used to define the minimum length supported. By default the value is set to 0.
  6. Maximum Length: A text field specific constraint used to define the maximum length supported. The default length is 80.
5. Default Value: Fixed Value: You can define a static value for the payload, for a boolean field.
6. Add lookups or enums for the custom attribute:
  1. Click Fields within the corresponding standard object.
  2. On the Fields page, Custom section, click Create.
  3. On the Select Field Type dialog box, select a corresponding type. You must select Choice List and click OK.
  4. Enter the following information:
    1. Display Name: This field is mandatory. The display name is visible for a user in Application Composer.
    2. API Name: This gets generated automatically based on the display name and is used in the payload.
    3. Required: Selecting this makes the attribute mandatory with the service payload. It's suggested to not enable this option for a custom attribute because this affects the base object. If you prefer to make an attribute or object as required, you can restrict in schema.
    4. Updatable: This is checked by default. Disabling this will fail the update operation.
    5. Searchable: This is related to Application Composer REST service and isn't used in this scenario.
  5. Click Add in the Lookup Type section and add the following information:
    1. Meaning: This field is mandatory as it serves as the display name.
    2. Lookup type: Code to identify lookup. Unique code to identify the list.
    3. Description: Add description about the lookup.
    4. To add values to lookup, click Actions> Create.
    5. Meaning: This field is mandatory as it serves as the display name.
    6. Lookup type: Code to identify lookup value.
    7. Description: Add description about the lookup.
    8. Enabled: Select to either enable or disable a particular value usage.
    9. Display Sequence: Specify the order of display.
7. Click Save and verify the changes.
8. Go to sandbox and publish the sandbox.

The schema is modified as type array.

title: ConsumerListOffer
type: object
description: 'It's designed to model flexible interface definition in order to provide maximal reuse for existing rating algorithms.'
allOf:
  - $ref: 'ProductOfferingOracle.yml'
  - properties:
      ConsumerList:
        type: array
        description: Consumer List Reference
        items:
          type: object
          description: Consumer List Reference
          properties:
            ConsumerName:
              type: string
              description: Consumer name details
            ConsumerCode:
              type: string
              description: Consumer code details

The schema is saved as ConsumerListOffer.yml and uploaded to the custom folder using schema endpoint as described in Upload schema section. For more information on uploading schema, see the section in this topic on uploading schema via Launch schema endpoint.

After the schema is uploaded, use the REST API endpoints to POST and GET data. Here's a sample payload and the steps to go about testing:

Publish the sandbox and verify the changes.
Upload the custom schema created with extension attributes to custom folder using schema upload endpoint.
Use the resource endpoint to trigger extension. For example, https://<hostname>/crmRestApi/atcProductCatalog/11.13.18.05/tmf-api/productCatalogManagement/v4/productOffering.

To test the scenario, the following payload can be used, with @type as ConsumerListOffer to trigger the extension.

{
    "id": "SUP_PS_WS_ROAM_301",
    "name": "Consumer List Spec 302",
    "description": "Product Specification for Wireless Roaming",
    "version": "1.0",
    "lifecycleStatus": "In design",
    "@type": "ConsumerListOffer",
    "@baseType": "ProductOfferingOracle",
    "project": {
        "name": "P_16_9_2020_11_55_15",
        "id": "P_16_9_2020_11_55_15"
    },
    "validFor": {
        "startDateTime": "2020-09-14T00:00:00.000Z"
    },
    "ConsumerList": [
        {
            "ConsumerName": "Consumer 1",
            "ConsumerCode": "CS-01"
        },
        {
            "ConsumerName": "Consumer 2",
            "ConsumerCode": "CS-02"
        }
    ]
}

Note:

You can't undo the changes for simple attribute or complex attribute objects after publishing the sandbox. Once it's published the changes will remain. So, creating a simple extension attribute with Required as enabled isn't recommended. To make an attribute as required, you must modify the schema and mark it as required within the schema.
Application composer can't handle complex extension types such as object or array specifically. Creating child objects and adding custom fields are common to both the scenarios. You can restrict the type of extension in schema only as explained earlier.

Migration of Extensions

Any implementation of Oracle Applications Cloud usually requires migrating extensions from one environment to another at various points in the subscription lifecycle. It's recommended to start with a test instance, test the changes, and only after validation, apply the changes to the production instance.

The extension configured in one instance can be moved to another either by manually configuring or by using the migration tool for Application Composer related changes.

For schema changes, you must manually move the changes after migrating Application Composer changes. Custom schema can be uploaded to the custom folder using schema endpoint as described in the following section.

Upload Schema via Launch Cloud Service Schema Endpoint

Use the Launch Cloud Service schema endpoint to upload new or updated YML files. Here's how you can go about it:

Go to endpoint: https://<hostname>/crmRestApi/atcProductCatalog/11.13.18.05/v1/schema.
Set Method to POST (to add new schema) or PUT (to overwrite an existing schema).
Request Body: Set mimeType as multipart or form-data.

Add the following rows inside the form:

Table 7-1 Values for Keys

Key	Value
path	custom
primaryFile	Select the file to be uploaded

Send the request.
Validate to ensure that the extension works.

Resource Details

Use this topic to understand the base and the extended resources shipped with the Launch application. You will require the resource details to be able to extend these resources using schema-based extension.

This table contains the resources with their corresponding YML names.

Table 7-2 YML Names of Resources

Catalog Resources	Oracle Shipped Extensions	YML Schema Name	Application Composer Object Name
Product Offer	ProductOfferingOracle	ProductOfferingOracle.yml	Launch Product Offerings
Product Offering Price	ProductOfferingPriceOracle ProductOfferPriceAllowanceOracle ProductOfferPriceOverageOracle ProductOfferPricePlanOracle ProductOfferPriceAlterationOracle	ProductOfferingPriceOracle.yml ProductOfferPriceAllowanceOracle.yml ProductOfferPriceOverageOracle.yml ProductOfferPricePlanOracle.yml ProductOfferPriceAlterationOracle.yml	Launch Product Offering Prices
Product Specification	ProductSpecificationOracle	ProductSpecificationOracle.yml	Launch Product Specifications
Pricing Logic Algorithm	PricingLogicAlgorithmOracle	PricingLogicAlgorithmOracle.yml	Launch Pricing Logic Algorithms
PLA Specification	PricingLogicAlgorithmSpecOracle UsagePLASpecOracle OneTimePLASpecOracle RecurringPLASpecOracle	PricingLogicAlgorithmSpecOracle.yml UsagePLASpecOracle.yml OneTimePLASpecOracle.yml RecurringPLASpecOracle.yml	Launch Pricing Logic Algorithm Specifications
Product Line	ProductLineOracle	ProductLineOracle.yml	Launch Product Lines
Project	ProjectOracle	ProjectOracle.yml	Launch Initiatives
Catalog	CatalogOracle	CatalogOracle.yml	Launch Catalogs
Category	CategoryOracle	CategoryOracle.yml	Launch Categories
Customer Profile Specification	CustomerProfileSpecificationOracle	CustomerProfileSpecificationOracle.yml	Launch Customer Profile Specifications
Service Specification	ServiceSpecificationOracle	ServiceSpecificationOracle.yml	Launch Service Specifications
Tax Service Providers	TaxServiceProviderOracle	TaxServiceProviderOracle.yml	Launch Tax Service Providers
Usage Specification	UsageSpecificationOracle	UsageSpecificationOracle.yml	Launch Usage Specifications
Balance Element	BalanceElementOracle	BalanceElementOracle.yml	Launch Balance Elements
Promotion	PromotionOracle	PromotionOracle.yml	Launch Promotions
Custom Profile Specification	CustomProfileSpecificationOracle	CustomProfileSpecificationOracle.yml	Launch Custom Profile Specifications
Price List	PricelistOracle	PricelistOracle.yml	Launch Price Lists
Price Constraints	PricelistConstraintOracle	PricelistConstraintOracle.yml	Launch Price Constraints
Lifecycle Configuration	LifecycleConfigurationOracle	LifecycleConfigurationOracle.yml	Launch Lifecycle Configurations

Configure Lifecycle Status

Use this topic to understand how you can configure the lifecycle status and where you can find more information regarding the configuration.

The lifecycle configuration resource represents a set of lifecycle configurations and lifecycle states. Lifecycle of all resources transition based on the lifecycle configuration associated to the project to which a resource is added.

You can extend lifecycle configurations by adding more lifecycle states and defining the characteristics for a state by creating a new version of the lifecycle configuration. You can add custom states only between In design and Launched.

To understand how you can add a new version of lifecycle status, see Configure a New Lifecycle Status.

Extend Lookup Values

Use this topic to understand how you can add lookup values using the extensibility framework.

You can create additional values or extend the default value sets for lookups and make modifications as per your business requirements. Review the existing enumerations, if any, for the lookup value that you're changing and if you need to have the validation at the API layer, then it must be added to the enumerations.

Let's take the example of setting up the eligibility parameters and see how you can modify values for a lookup.

Go to Navigator > My Enterprise > Setup and Maintenance.
In Setup and Maintenance, click Tasks > Search and enter Manage Standard Lookups in the Search field.
On the Manage Standard Lookups page, search for the lookup either by name or code. For our example, search for the ORA_ATC_PARMTR to edit the eligibility parameter lookup. The ORA_ATC_PARMTR lookup type now appears in the Search Results section.

If you're not sure about the code, you can search with ORA_ATC_% in the Lookup Type section, which will show you all the LOVs in the application.
In the ORA_ATC_PARMTR: Lookup Codes section, update the LOVs as required. You can modify, add, or delete values.
Click Save after you're done with your changes.
Click Save and Close.

For more information about lookups, see Overview of Lookups.

Below are the details of the Lookups that you can extend in Launch.

Table 7-3 Extend Lookup Values

Fee Type	Lookup Type Code	Lookup Type Meaning	Usage in UI
One Time	ORA_ATC_ONE_TIME_FEE_TYPE	One-Time Fee Type	Price Type drop-down on the pricing screen when creating a One-Time Fee during offer creation. You can extend the one-time fee types by extending this lookup. For example, a new type called Activation could be added, so that one-time fee type can refer the same.

Extend Finance Plan

Use this topic to know how you can add lookup values to the existing finance plan.

The finance plan feature enables you to factor in interest based installment plans with amortization details (in addition to the current 0% interest based installment plans). You can create additional lookup values or extend the amortization attribute sets and make changes as per your business requirements. The extension to these attributes is currently supported only through the API layer.

Seeded Attributes

The following table shows the seeded attributes shipped with the Launch application.

Table 7-4 Seeded Attributes Shipped with the Launch Application

Amortization Characteristics	Characteristic Values
Interest Type	Simple Compound Factor
Pattern Type	Simple Range
Duration	Months Years
Interest Details Sub-characteristics: Range From Range To Interest	N/A
Entitlement Templates	N/A

You can add a new amortization characteristic or add new sub characteristics within the interest details. To add a new finance plan, you need to perform a PUT call on the REST API endpoint on crmRestApi/atcProductCatalog/11.13.18.05/productCatalogReferenceManagement/v1/customProfileSpecification/{id} with the profileType FINANCE_PLAN.

To access the finance plan template and to know about other related REST API details, see REST API Reference for Launch Cloud Service.

Add a Simple Characteristic

You can add a simple characteristic which takes free form text as input.

{
        "name": "COMPOUNDING TERM",
        "description": "If the interest type is Compound ,if it is compounded annually,half yearly or quarterly",
        "valueType": "STRING",
        "active": true
    }

Add Sub characteristics within Interest Details

To extend the interest details characteristic, specify the relation of the characteristic to the interest details, along with the following values.

{
                "name": "InterestConcession",
                "customProfileSpecCharValue": [
                    {
                        "valueTo": "1",
                        "valueType": "DECIMAL",
                        "isDefault": false
                    },
                    {
                        "valueTo": "2",
                        "valueType": "DECIMAL",
                        "isDefault": false
                    },
                    {
                        "valueTo": "3",
                        "valueType": "DECIMAL",
                        "isDefault": false
                    }
                ],
                 "customProfileSpecCharRel": [
                    {
                        "charSpecSeq": 1,
                        "id": "GlobalFinancePlan",
                        "relationshipType": "PARENT",
                        "name": "interestDetails"
                    }
                ]
            }


The Payload to Extend the Finance Plan can be found in the < Replace with Payload page URL to Sample Payload CustomProfileSpec>

Extended Attributes in Dynamic Forms

You can customize dynamic forms to show extended attributes for offers, product specification, and catalog.

You can edit the basic details form of these objects using VB Studio. Refer the VB Studio guide to understand how to make the changes.

You would need to do the following steps for Launch:

From the Settings and Actions menu in Visual Builder, click Edit Pages to open the page in the Designer in VB Studio.
Choose the form layout you need to edit. You may either duplicate the layout and make changes or create a new layout.
Add or remove fields from the new layout as needed. For the new fields, make sure that you create a new field and template under the Field as well as Template section. Ensure that the field is correctly mapped to the template under the fieldTemplateMap section in the layout JSON. Also, prefix all custom fields with "resourceExtension_dot" since custom fields are mapped under resourceExtension object. Here's a sample input text template for a custom Partner ID field for product offering:
```
<template id="partnerIdTemplate">
  <oj-input-text value="{{ $componentContext.pageVariables.productOfferingPayload.resourceExtension_dotPartnerId }}" label-hint="[[ 'Partner ID' ]]"
      readonly="[[ $componentContext.pageVariables.offerFlow === 'view' || $componentContext.pageVariables.offerFlow === 'revise']]"></oj-input-text>
</template>
```
You may refer the read-only definition of other fields in the layout template to use the correct variables.

For the input value to be included in the payload, you need to use two-way binding using curly braces to the correct variable as shown in the sample. In the sample, $componentContext.pageVariables.productOfferingPayload is the payload variable used for product offering. Similarly, use $componentContext.pageVariables.productSpecificationPayload for Product Specification and $componentContext.pageVariables.catalogPayload for Catalog.

After configuring the new layout, edit the rule set to show your layout based on _attype. A sample rule set definition for Product Offering, Product Specification, and Catalog is as follows:

$componentContext.pageVariables.productOfferingPayload._attype === 'PartnerOffer'? 'partnerLayout': 'default'

$componentContext.pageVariables.productSpecificationPayload['@type'] === 'TestProductSpecification' || $componentContext.pageVariables.getProductSpecificationByIdResponse['_attype'] === 'TestProductSpecification' ? 'customLayout': 'default'

$componentContext.pageVariables.catalogPayload['@type'] === 'TestCatalog' ? 'partnerCatalog': 'default'

Configure Layouts for Product Specifications

Use this topic to determine how you can create a layout file to display the extended product specification characteristics. These characteristics are displayed in the attributes train stop of the pages for creating or editing offers. A product specification can

Prerequisites

Here are some of the prerequisites:

The layout file name must be of the format: <Product Specification Id> -layout.json. For example, 5GSupremo-layout.json.
The layout file must be uploaded to the CatalogManagement/schema/Layouts directory in UCM. For steps on how to upload the layout file, refer Extension Types.
The layout file must have the following schema:

{
    "$schema": "http://json-schema.org/schema#",
    "id": "http://example.com/schemas/jet/npi-dynamic-layout-schema.json",
    "title": "NPIDynamicLayout",
    "description": "Describes the model for the NPI Dynamic Layout",
    "definitions": {
        "propertyLayout": {
            "description": "Defines a layout structure for a property",
            "type": "object",
            "properties": {
                "labelHint": {
                    "description": "Defines label for the property",
                    "type": "string"
                },
                "class": {
                    "description": "Class to be applied to this property. Used for overriding input components",
                    "type": "string"
                }
            },
            "additionalProperties": false
        },
        "displayProperties": {
            "description": "Defines structure of displayProperties used by formLayout",
            "type": "array",
            "items": {
                "anyOf": [{
                    "type": "string"
                }, {
                    "type": "object",
                    "patternProperties": {
                        "^[\\$A-Z_a-z][\\$A-Z_a-z0-9/-]*$": {
                            "$ref": "#/definitions/propertyLayout"
                        }
                    }
                }]
            }
        },
        "formLayout": {
            "properties": {
                "labelHint": {
                    "type": "string"
                },
                "displayProperties": {
                    "$ref": "#/definitions/displayProperties"
                }
            },
            "additionalProperties": false
        },
        "singleLayout": {
            "description": "Definition of the single layout structure",
            "type": "object",
            "properties": {
                "description": {
                    "type": "string"
                },
                "layoutType": {
                    "type": "string"
                },
                "layout": {
                    "$ref": "#/definitions/formLayout"
                }
            },
            "additionalProperties": false
        }
    },
    "type": "object",
    "properties": {
        "layouts": {
            "description": "The layouts definition",
            "patternProperties": {
                "^[\\$A-Z_a-z][\\$A-Z_a-z0-9/-]*$": {
                    "$ref": "#/definitions/singleLayout"
                }
            },
            "additionalProperties": false
        }
    },
    "additionalProperties": false
}

How To Go About It

After you have set up your prerequisites, set up the UI layouts in the following way.

Add and Order Fields in a Layout

To make a field visible on the UI, you must define it in layout.json. The order of the fields in the UI is the order of the fields in layout.json. Here's an example.

{
    "layouts": {
        "phone-form": {
            "description": "layout for phone form with grouping support",
            "layoutType": "form",
            "layouts": {
                "apple": {
                    "layoutType": "form",
                    "layout": {
                        "description": "form layout for apple iPhone",
                        "displayProperties": ["storageSpace", "chipName", "batteryCapacity", "operatingSystem"]
                    }
                }
            }
        }
    }
}

Create Groups in a Layout

Here's an example that shows how you can create groups.

{
    "layouts": {
        "phone-form": {
            "description": "layout for phone form with grouping support",
            "layoutType": "form",
            "layouts": {
                "apple": {
                    "layoutType": "form",
                    "layout": {
                        "description": "form layout for apple iPhone",
                        "displayProperties": [{
                            "physical": {
                                "description": "layout for physical group",
                                "layoutType": "form",
                                "layout": {
                                    "labelHint": "Physical",
                                    "displayProperties": ["widthValue", "heightValue", "weightValue", "dateOfManufacture", "dateOfRelease", "detailedDescription"]
                                }
                            }
                        }, {
                            "technical": {
                                "description": "layout for technical group",
                                "layoutType": "form",
                                "layout": {
                                    "labelHint": "Technical",
                                    "displayProperties": ["storageSpace", "chipName", "batteryCapacity", "operatingSystem"]
                                }
                            }
                        }, {
                            "logistics": {
                                "description": "layout for logistics group",
                                "layoutType": "form",
                                "layout": {
                                    "labelHint": "Logistics",
                                    "displayProperties": ["shippingCarriers", "vendorPartNum", "shippingTime"]
                                }
                            }
                        }]
                    }
                }
            }
        }
    }
}

Override Labels

You must use the labelHint property to override UI labels. Here's an example of shippingMethod that shows how to override labels.

{
    "layouts": {
        "phone-form": {
            "description": "layout for phone form with grouping support",
            "layoutType": "form",
            "layouts": {
                "apple": {
                    "layoutType": "form",
                    "layout": {
                        "description": "form layout for apple iPhone",
                        "displayProperties": [{
                            "physical": {
                                "description": "layout for physical group",
                                "layoutType": "form",
                                "layout": {
                                    "labelHint": "Physical",
                                    "displayProperties": ["widthValue", "heightValue", "weightValue", "dateOfManufacture", "dateOfRelease", "detailedDescription"]
                                }
                            }
                        }, {
                            "technical": {
                                "description": "layout for technical group",
                                "layoutType": "form",
                                "layout": {
                                    "labelHint": "Technical",
                                    "displayProperties": ["storageSpace", "chipName", "batteryCapacity", "operatingSystem"]
                                }
                            }
                        }, {
                            "logistics": {
                                "description": "layout for logistics group",
                                "layoutType": "form",
                                "layout": {
                                    "labelHint": "Logistics",
                                    "displayProperties": ["shippingCarriers", {"shippingMethod":{"labelHint": "Available Shipping Methods"}}, "shippingTime"]
                                }
                            }
                        }]
                    }
                }
            }
        }
    }
}

Override UI Controls

You must use the class property to override UI controls. Here's an example of shippingRequiredFlag that shows how to override the input component for a field.

{
    "layouts": {
        "phone-form": {
            "description": "layout for phone form with grouping support",
            "layoutType": "form",
            "layouts": {
                "apple": {
                    "layoutType": "form",
                    "layout": {
                        "description": "form layout for apple iPhone",
                        "displayProperties": [{
                            "physical": {
                                "description": "layout for physical group",
                                "layoutType": "form",
                                "layout": {
                                    "labelHint": "Physical",
                                    "displayProperties": ["widthValue", "heightValue", "weightValue", "dateOfManufacture", "dateOfRelease", "detailedDescription"]
                                }
                            }
                        }, {
                            "technical": {
                                "description": "layout for technical group",
                                "layoutType": "form",
                                "layout": {
                                    "labelHint": "Technical",
                                    "displayProperties": ["storageSpace", "chipName", "batteryCapacity", "operatingSystem"]
                                }
                            }
                        }, {
                            "logistics": {
                                "description": "layout for logistics group",
                                "layoutType": "form",
                                "layout": {
                                    "labelHint": "Logistics",
                                    "displayProperties": ["shippingCarriers", "vendorPartNum", {"shippingRequiredFlag":{"class":"boolean-radioset-yn"}}, "shippingTime"]
                                }
                            }
                        }]
                    }
                }
            }
        }
    }
}

Override Field Controls

You must use the following set of values.

Boolean

Table 7-5 Override Field Controls- Boolean

What you use	How it's rendered
boolean-checkbox	As a check box. This is the default.
boolean-radioset-yn	As a radio set with a Yes or No option.
boolean-radioset-tf	As a radio set with a True or False option.
boolean-dropdown-yn	As a drop-down list with a Yes or No option.
boolean-dropdown-tf	As a drop-down list with a True or False option.

LOV

Table 7-6 Override Field Controls- LOV

What you use	How it's rendered
lov-dropdown	As a drop-down list. This is the default.
lov-radioset	As a radio set.