.. This work is licensed under a Creative Commons Attribution 4.0 International License. .. http://creativecommons.org/licenses/by/4.0 .. Copyright 2017 Huawei Technologies Co., Ltd. .. _open_cli_schema_version_1_0: Open Command Line Interface (CLI) Schema Version (OCS) 1.0 ========================================================== Open CLI Platform (OCLIP) provides model based framework to implement Linux Commands for any given software products, by using YAML template based on the schematics defined in this document. In version 1.0, following aspects of commands are modeled as YAML schematics: * Software product/service information * Command line arguments * Command outputs * Command execution details like HTTP, SNMP (profiles) * Command usage and samples open_cli_schema_version ----------------------- OCLIP considers any YAML file with first line having the following entry as OCS template. open_cli_schema_version: 1.0 Here, 1.0 version is first version of this schema. In future, this version number will get incremented based on addition of new schematics or update of existing schematics. name ---- *name* entry allows to set the command name and it is recommended to use the following format: - entity - Resource or a feature, for which command is provided action - Functionality performed on the entity For example, to implement a command to *start* a given *service*. set the name as: **name** : **service-start** *CAUTION*: name should not have any space character in it. description ----------- *description* entry allows to write detailed usage of the command. It could be a line or a paragraph as given example here. **a line** description: Start the given service **a paragraph** description: | Start the given service. To see the available services in the system use the command *service-list* info ------- product ~~~~~~~~ *product* entry allows to tag the command template with the software product name and version, for which command is implemented and is recommended to use the following format: - product - Short name of the product action - Version of the product For example, to implement a command for Open Network Automation Platform (onap) version amsterdam, set the version as: **product** : **onap-amsterdam** *CAUTION*: product should not have any space character in it. parameters --------- Every command has set of arguments to provide the input values and *parameters* section allows to add the required arguments details such as name, description, etc as list of entries. name ~~~~ *name* entry uniquely identifies the given argument. It can be of any alpha-numerical characters and dash(-). For example to provide the http port of an service, the parameter could be: parameters: \- **name: service-port** description ~~~~~~~~~~~ *description* entry allows to provide the details of the parameter. Its supported in similar approach with command *description* defined in above section. For example service-port could be described as: parameters: \- name: service-port **description: Service HTTP port.** is_optional ~~~~~~~~~~~ *is_optional* entry allows to set the parameter is mandatory or not. By default, this entry is false. For example service-port could be made as as optional: parameters: \- name: service-port description: Service HTTP port. **is_optional: true** is_secured ~~~~~~~~~~~ *is_secured* entry allows to set the parameter is secured or not. By default, this entry is false. This is very useful for password kind of parameters. For example service-port could be made as in-secured: parameters: \- name: service-port description: Service HTTP port. is_optional: true **is_secured: false** default_value ~~~~~~~~~~~~~ *default_value* entry helps to provide the default value for the given parameter when that parameter is not provided during command execution. Based on the *type* of parameter, default values are assigned as: +---------------+------------------------------------------------------------+ | Type | Default value | +===============+============================================================+ | bool | false | +---------------+------------------------------------------------------------+ | uuid | Auto-generated uuid-4 string | +---------------+------------------------------------------------------------+ | string | Blank. Also it can be set default values from the system | | | environment variable by mentioning it in the form of : | | | | | | parameters: | | | - default_value: ${ENV-VARIABLE-NAME} | +---------------+------------------------------------------------------------+ For example to provide the http port of an service, the parameter could be: parameters: \- name: service-port description: Service HTTP port. is_optional: true is_secured: false **default_value: 8080** type ~~~~ *type* entry allows to set the type of parameter such as boolean, integer, etc. For example to provide the http port of an service, the parameter type could be: parameters: \- name: service-port description: Service HTTP port. is_optional: true is_secured: false default_value: 8080 **type: long** Platform supports following types of parameter: string ^^^^^^ Any parameter value having a work or a line, string type is appropriate one. By default it is set to blank. digit ^^^^^^ Any param

'use strict';

export class OperationParam {
    paramName: string = '';
    paramId: string = '';

    constructor(param?: OperationParam) {
        if (param) {
            this.paramId = param.paramId;
            this.paramName = param.paramName;
        }
    }
}

export interface IOperationParamsList {
    listToscaDataDefinition: Array<OperationParam>;
}

export class OperationModel {
    description: string;
    inputParams: IOperationParamsList;
    operationType: string;
    outputParams: IOperationParamsList;
    uniqueId: string;

    constructor(operation?: any) {
        if (operation) {
            this.description = operation.description;
            this.inputParams = operation.inputParams;
            this.operationType = operation.operationType;
            this.outputParams = operation.outputParams;
            this.uniqueId = operation.uniqueId;
        }
    }

    public createInputParamsList(inputParams: Array<OperationParam>): void {
        this.inputParams = {
            listToscaDataDefinition: inputParams
        };
    }

    public createOutputParamsList(outputParams: Array<OperationParam>): void {
        this.outputParams = {
            listToscaDataDefinition: outputParams
        };
    }
}

export interface CreateOperationResponse extends OperationModel {
    artifactUUID: string;
}

T headers: header1: value1 header2: value2 queries ^^^^^^^ *queries* entry allows to add REST API specific queries. For example, to add the sample queries : request: uri: /resource1 method: GET queries: q1: value1 q2: value2 context ^^^^^^^ *context* entry allows to customize the HTTP request and response processing. Following are the supported customization parameters: *remove_empty_node* : By default, OCLIP does not remove the empty json entries in request body. Otherwise set this entry to true as below. request: context: remove_empty_node: true success_codes ~~~~~~~~~~~~~ Every REST API has set of success codes and OCLIP will treat the HTTP request made based on the value configured in these http sections, only if *success_codes* contains the HTTP response status code. result_map ~~~~~~~~~~ This section allows to configure the require 'jpath' expression to retrieve the values from the HTTP response body. *NOTE*: Currently only http response body is supported only with json type. For example, if a http response '{"service_status": "green"} then to retrieve the service status and assign to result *attribute* service_status as : result_map: service_status: $b{$.service_status} Here, $b is detailed in section 'macros' of this document. and '$.service_status' is jpath expression. macros ------- OCLIP platform provides various marcos to fill *http* entries with the value of *parameters*, *headers* , etc Every macro is in the form of followed by {}Followings are the supported macros: +------------------+------------------------------------------------------------+ | Macro | Definitions | +==================+============================================================+ | ${param-name} | To retrieve the value from parameter named 'param-name' | +------------------+------------------------------------------------------------+ | $s{env:env-name} | To retrieve the value from environment variable 'env-name' | +------------------+------------------------------------------------------------+ | $s{uuid} | To set the value in uuid4 format | +------------------+------------------------------------------------------------+ | $h{header-name} | To retrieve the value from header named 'header-name' | +------------------+------------------------------------------------------------+ | $q{query-name} | To retrieve the value from query named 'query-name' | +------------------+------------------------------------------------------------+ | $b{jpath} | To retrieve the value from response body using the 'jpath' | | | expression. | +------------------+------------------------------------------------------------+ samples ------- OCLIP provides way to setup and verify the OCS yaml by using the open_cli_sample_version 1.0 specification, which provides options to capture the samples and expected out for the given moco environment.