Modeling API

There are two Tosca Parsers submited into modeling project, their API are listed below:

• Openstack Tosca Parser API: (Python)

 1) use cli, which is used to validate tosca simple based service template. It can be used as:

        tosca-parser --template-file=<path to the YAML template>  [--nrpv]  [--debug]

        tosca-parser --template-file=<path to the CSAR zip file> [--nrpv]  [--debug]

        tosca-parser --template-file=<URL to the template or CSAR>  [--nrpv]  [--debug]

    options:

      --nrpv Ignore input parameter validation when parse template.

     --debug debug mode for print more details other than raise exceptions when errors happen

  2) use api, which is used to parse and get the result of service template. it can be used as

   ToscaTemplate(path=None, parsed_params=None, a_file=True, yaml_dict_tpl=None, 

                                          sub_mapped_node_template=None,

                                          no_required_paras_valid=False, debug=False )

• Java based Tosca Parser API: (Java)
  

1. Java API
   The Java API is described in detail in the javadoc. The main classes are part of the package org.onap.tosca.checker. The entry point is the Checker class, the TOSCA service templates are represented by the Target class an the results of the processing are represented by Report (contains errors associated with a Target) and Catalog (if successful, i.e. empty report, contains an index of TOSCA constructs).
   Common usage:

   try {
     Catalog cat = Checker.check(uri_or_path_of_service_template);

     for (Target t: cat.targets()) {
       System.err.println(t.getLocation() + "\n" + t.getReport());
     }

   }

   catch (Exception x) {
     /* error handling */
   }

   
    The API offers options for custom TOSCA dialects (extended grammars), pluggable validation and consistency checking, different post-processing approaches.

2. CLI tool
   The Maven based build assembles a 'all-in-one' jar (in the checker sub-project) with a convenient entry point for cli based validation:

       java -jar Checker-0.0.1-SNAPSHOT-jar-with-dependencies.jar path_to_service_template_file

   
   

3. REST service
   The same functionality is offered as a REST-based service. The service sub-project assembles a spring framework based REST interface with a built in default configuration. The package is found in the  service sub-project. To start the service:

       java -jar Service-0.0.1-SNAPSHOT.jar

   Sample client usage (windows power shell):

       PS C:\Users\serban> Invoke-WebRequest -Uri http://localhost:8080/check_template/ -Method Post -ContentType application/json -InFile C:\src\asc-tosca\DCAE\v3\Database\Postgres-generic\schema.yaml

   or with stateful 'namespaces':

       PS C:\Users\serban> Invoke-WebRequest -Uri http://localhost:8080/check_template/database/schema.yaml -Method Post -ContentType application/json -InFile C:\src\asc-tosca\DCAE\v3\Database\Postgres-generic\schema.yaml

       PS C:\Users\serban> Invoke-WebRequest -Uri http://localhost:8080/check_template/database -Method Post -ContentType application/json -InFile C:\src\asc-tosca\DCAE\v3\Database\Postgres-generic\template_postgres.yaml

   The first call creates the 'database' namespace and registers the submitted template as 'schema.yaml'. The second call submits a template as part of the same namespace containing an import of schema.yaml (from the first call); this mechanism allows for validation of multiple service templates with the same schema/type system.

   For more details on the different REST API usages see the service sub-project documentation.