# Module `netapp_ontap.resources.application`

Copyright © 2021 NetApp Inc. All rights reserved.

## Classes

`class Application (*args, **kwargs)`

  Applications

  Initialize the instance of the resource.

  Any keyword arguments are set on the instance as properties. For example, if the class was named 'MyResource', then this statement would be true:

      MyResource(name='foo').name == 'foo'

  ## Args

  `*args`
    Each positional argument represents a parent key as used in the URL of the object. That is, each value will be used to fill in a segment of the URL which refers to some parent object. The order of these arguments must match the order they are specified in the URL, from left to right.
  `**kwargs`
    each entry will have its key set as an attribute name on the instance and its value will be the value of that attribute.

  ### Ancestors

  - Resource

  ### Static methods

  `def count_collection(*args, connection: HostConnection = None, **kwargs) -> int`

    Retrieves applications.

    ### Expensive properties

    There is an added cost to retrieving values for these properties. They are not included by default in GET results and must be explicitly requested using the `fields` query parameter. See `Requesting specific fields` to learn more. * `<template>` the property corresponding to the `template.name` of the application

    ### Query examples

    Numerous queries are available for classifying and sorting applications: 1. Return a list of applications sorted by name. `GET /application/applications?order_by=name`
    2. Return a list of applications for a specific SVM. `GET /application/applications?svm.name=<name>`
    3. Return a list of all SQL applications. `GET /application/applications?template.name=sql*`
    4. Return a list of all applications that can be accessed via SAN.
    `GET /application/applications?template.protocol=san`
    5. Return the top five applications consuming the most IOPS.
    `GET /application/applications?order_by=statistics.iops.total desc&max_records=5`
    The above examples are not comprehensive. There are many more properties available for queries. Also, multiple queries can be mixed and matched with other query parameters for a large variety of requests. See the per-property documentation below for the full list of supported query parameters.

    ### Learn more

    - `DOC /application`

    Fetch a count of all objects of this type from the host.

    This calls GET on the object to determine the number of records. It is more efficient than calling get_collection() because it will not construct any objects. Query parameters can be passed in as kwargs to determine a count of objects that match some filtered criteria.

    ## Args

    `*args`
      Each entry represents a parent key which is used to build the path to the child object. If the URL definition were /api/foos/{foo.name}/bars, then to get the count of bars for a particular foo, the foo.name value should be passed.
    `connection`
      The `HostConnection` object to use for this API call. If unset, tries to use the connection which is set globally for the library or from the current context.
    `**kwargs`
      Any key/value pairs passed will be sent as query parameters to the host. These query parameters can affect the count. A return_records query param will be ignored.

    ## Returns

    On success, returns an integer count of the objects of this type. On failure, returns -1.

    ## Raises

    `NetAppRestError`: If the API call returned a status code >= 400, or if there is no connection available to use either passed in or on the library.

  `def delete_collection(*args, body: typing.Union = None, connection: HostConnection = None, **kwargs) -> NetAppResponse`

    Deletes an application and all associated data.

    ### Warning - this deletes it all, including your data

    This deletes everything created with the application, including any volumes, LUNs, NFS export policies, CIFS shares, and initiator groups. Initiator groups are only destroyed if they were created as part of an application and are no longer in use by other applications.

    ### Learn more

    - `DOC /application`
    - `Asynchronous operations`

    Delete all objects in a collection which match the given query.

    All records on the host which match the query will be deleted.

    ## Args

    `*args`
      Each entry represents a parent key which is used to build the path to the child object. If the URL definition were /api/foos/{foo.name}/bars, then to delete the collection of bars for a particular foo, the foo.name value should be passed.
    `body`
      The body of the delete request. This could be a Resource instance or a dictionary object.
    `connection`
      The `HostConnection` object to use for this API call. If unset, tries to use the connection which is set globally for the library or from the current context.
    `**kwargs`
      Any key/value pairs passed will be sent as query parameters to the host. Only resources matching this query will be deleted.

    ## Returns

    A `NetAppResponse` object containing the details of the HTTP response.

    ## Raises

    `NetAppRestError`: If the API call returned a status code >= 400

  `def find(*args, connection: HostConnection = None, **kwargs) -> Resource`

    Retrieves applications.

    ### Expensive properties

    There is an added cost to retrieving values for these properties. They are not included by default in GET results and must be explicitly requested using the `fields` query parameter. See `Requesting specific fields` to learn more. * `<template>` the property corresponding to the `template.name` of the application

    ### Query examples

    Numerous queries are available for classifying and sorting applications: 1. Return a list of applications sorted by name. `GET /application/applications?order_by=name`
    2. Return a list of applications for a specific SVM. `GET /application/applications?svm.name=<name>`
    3. Return a list of all SQL applications. `GET /application/applications?template.name=sql*`
    4. Return a list of all applications that can be accessed via SAN.
    `GET /application/applications?template.protocol=san`
    5. Return the top five applications consuming the most IOPS.
    `GET /application/applications?order_by=statistics.iops.total desc&max_records=5`
    The above examples are not comprehensive. There are many more properties available for queries. Also, multiple queries can be mixed and matched with other query parameters for a large variety of requests. See the per-property documentation below for the full list of supported query parameters.

    ### Learn more

    - `DOC /application`

    Find an instance of an object on the host given a query.

    The host will be queried with the provided key/value pairs to find a matching resource. If 0 are found, None will be returned. If more than 1 is found, an error will be raised or returned. If there is exactly 1 matching record, then it will be returned.

    ## Args

    `*args`
      Each entry represents a parent key which is used to build the path to the child object. If the URL definition were /api/foos/{foo.name}/bars, then to find a bar for a particular foo, the foo.name value should be passed.
    `connection`
      The `HostConnection` object to use for this API call. If unset, tries to use the connection which is set globally for the library or from the current context.
    `**kwargs`
      Any key/value pairs passed will be sent as query parameters to the host.

    ## Returns

    A `Resource` object containing the details of the object or None if no matches were found.

    ## Raises

    `NetAppRestError`: If the API call returned more than 1 matching resource.

  `def get_collection(*args, connection: HostConnection = None, max_records: int = None, **kwargs) -> typing.Iterable`

    Retrieves applications.

    ### Expensive properties

    There is an added cost to retrieving values for these properties. They are not included by default in GET results and must be explicitly requested using the `fields` query parameter. See `Requesting specific fields` to learn more. * `<template>` the property corresponding to the `template.name` of the application

    ### Query examples

    Numerous queries are available for classifying and sorting applications: 1. Return a list of applications sorted by name. `GET /application/applications?order_by=name`
    2. Return a list of applications for a specific SVM. `GET /application/applications?svm.name=<name>`
    3. Return a list of all SQL applications. `GET /application/applications?template.name=sql*`
    4. Return a list of all applications that can be accessed via SAN.
    `GET /application/applications?template.protocol=san`
    5. Return the top five applications consuming the most IOPS.
    `GET /application/applications?order_by=statistics.iops.total desc&max_records=5`
    The above examples are not comprehensive. There are many more properties available for queries. Also, multiple queries can be mixed and matched with other query parameters for a large variety of requests. See the per-property documentation below for the full list of supported query parameters.

    ### Learn more

    - `DOC /application`

    Fetch a list of all objects of this type from the host.

    This is a lazy fetch, making API calls only as necessary when the result of this call is iterated over. For instance, if max_records is set to 5, then iterating over the collection causes an API call to be sent to the server once for every 5 records. If the client stops iterating before getting to the 6th record, then no additional API calls are made.

    ## Args

    `*args`
      Each entry represents a parent key which is used to build the path to the child object. If the URL definition were /api/foos/{foo.name}/bars, then to get the collection of bars for a particular foo, the foo.name value should be passed.
    `connection`
      The `HostConnection` object to use for this API call. If unset, tries to use the connection which is set globally for the library or from the current context.
    `max_records`
      The maximum number of records to return per call
    `**kwargs`
      Any key/value pairs passed will be sent as query parameters to the host.

    ## Returns

    A list of `Resource` objects

    ## Raises

    `NetAppRestError`: If there is no connection available to use either passed in or on the library. This would be not be raised when get_collection() is called, but rather when the result is iterated.

  `def patch_collection(body: dict, *args, connection: HostConnection = None, **kwargs) -> NetAppResponse`

    Updates the properties of an application.

    ### Overview

    Similar to creating an application, modification is done using the template properties of an application. The `storage_service`, `size`, and `igroup_name` of an application may be modified.

    ### `storage_service`

    Storage service modifications are processed in place, meaning that the storage can not be moved to a location with more performance headroom to accommodate the request. If the current backing storage of the application is in a location that can support increased performance, the QoS policies associated with the application will be modified to allow it. If not, an error will be returned. A storage service modification to a lower tier of performance is always allowed, but the reverse modification may not be supported if the cluster is over provisioned and the cluster is unlikely to be able to fulfil the original storage service.

    ### `size`

    Size modifications are processed in a variety of ways depending on the type of application. For NAS applications, volumes are grown or new volumes are added. For SAN applications, LUNs are grown, new LUNs are added to existing volumes, or new LUNs are added to new volumes. If new storage elements are created, they can be found using the `GET /application/applications/{application.uuid}/components` interface. The creation time of each storage object is included, and the newly created objects will use the same naming scheme as the previous objects. Resize follows the best practices associated with the type of application being expanded. Reducing the size of an application is not supported.

    ### `igroup_name`

    Modification of the igroup name allows an entire application to be mapped from one initiator group to another. Data access will be interrupted as the LUNs are unmapped from the original igroup and remapped to the new one.

    ### Application state

    During a modification, the `state` property of the application updates to indicate `modifying`. In `modifying` state, statistics are not available and Snapshot copy operations are not allowed. If the modification fails, it is possible for the application to be left in an inconsistent state, with the underlying ONTAP storage elements not matching across a component. When this occurs, the application is left in the `modifying` state until the command is either retried and succeeds or a call to restore the original state is successful.

    ### Examples

    1. Change the storage service of the database of the Oracle application to extreme and resize the redo logs to 100GB. `{ "oracle_on_nfs": { "db": { "storage_service": { "name": "extreme" } }, "redo_log": { "size": "100GB" } } }`
    2. Change the storage service, size, and igroup of a generic application by component name. `{ "san": { "application_components": [ { "name": "component1", "storage_service": { "name": "value" } }, { "name": "component2", "size": "200GB" }, { "name": "component3", "igroup_name": "igroup5" } ] } }`

    ### Learn more

    - `DOC /application`
    - `Asynchronous operations`

    Patch all objects in a collection which match the given query.

    All records on the host which match the query will be patched with the provided body.

    ## Args

    `body`
      A dictionary of name/value pairs to set on all matching members of the collection.
    `*args`
      Each entry represents a parent key which is used to build the path to the child object. If the URL definition were /api/foos/{foo.name}/bars, then to patch the collection of bars for a particular foo, the foo.name value should be passed.
    `connection`
      The `HostConnection` object to use for this API call. If unset, tries to use the connection which is set globally for the library or from the current context.
    `**kwargs`
      Any key/value pairs passed will be sent as query parameters to the host. Only resources matching this query will be patched.

    ## Returns

    A `NetAppResponse` object containing the details of the HTTP response.

    ## Raises

    `NetAppRestError`: If the API call returned a status code >= 400

  ### Methods

  `def delete(self, body: typing.Union = None, poll: bool = True, poll_interval: typing.Union = None, poll_timeout: typing.Union = None, **kwargs) -> NetAppResponse`

    Deletes an application and all associated data.

    ### Warning - this deletes it all, including your data

    This deletes everything created with the application, including any volumes, LUNs, NFS export policies, CIFS shares, and initiator groups. Initiator groups are only destroyed if they were created as part of an application and are no longer in use by other applications.

    ### Learn more

    - `DOC /application`
    - `Asynchronous operations`

    Send a deletion request to the host for this object.

    ## Args

    `body`
      The body of the delete request. This could be a Resource instance or a dictionary object.
    `poll`
      If set to True, the call will not return until the asynchronous job on the host has completed. Has no effect if the host did not return a job response.
    `poll_interval`
      If the operation returns a job, this specifies how often to query the job for updates.
    `poll_timeout`
      If the operation returns a job, this specifies how long to continue monitoring the job's status for completion.
    `**kwargs`
      Any key/value pairs passed will be sent as query parameters to the host.

    ## Returns

    A `NetAppResponse` object containing the details of the HTTP response.

    ## Raises

    `NetAppRestError`: If the API call returned a status code >= 400

  `def get(self, **kwargs) -> NetAppResponse`

    Retrieves an application

    ### Expensive properties

    There is an added cost to retrieving values for these properties. They are not included by default in GET results and must be explicitly requested using the `fields` query parameter. See `Requesting specific fields` to learn more. * `<template>` the property corresponding to the `template.name` of the application

    ### Property overview

    An application includes three main groups or properties. * Generic properties - such as the `name`, `template.name`, and `state` of the application. These properties are all inexpensive to retrieve and their meaning is consistent for every type of application. * `statistics.*` - application statistics report live usage data about the application and its components. Various space and IOPS details are included at both the application level and at a per component level. The application model includes a detailed description of each property. These properties are slightly more expensive than the generic properties because live data must be collected from every storage element in the application. * `<template>` - the property corresponding to the value of the `template.name` returns the contents of the application in the same layout that was used to provision the application. This information is very expensive to retrieve because it requires collecting information about all the storage and access settings for every element of the application. There are a few notable limitations to what can be returned in the `<template>` section: * The `new_igroups` array of many SAN templates is not returned by GET. This property allows igroup creation in the same call that creates an application, but is not a property of the application itself. The `new_igroups` array is allowed during PATCH operations, but that does not modify the `new_igroups` of the application. It is another way to allow igroup creation while updating the application to use a different igroup. * The `vdi_on_san` and `vdi_on_nas` `desktops.count` property is rounded to the nearest 1000 during creation, and is reported with that rounding applied. * The `mongo_db_on_san` `dataset.element_count` property is rounded up to an even number, and is reported with that rounding applied. * The `sql_on_san` and `sql_on_smb` `server_cores_count` property is limited to 8 for GET operations. Higher values are accepted by POST, but the impact of the `server_cores_count` property on the application layout currently reaches its limit at 8.

    ### Learn more

    - `DOC /application`

    Fetch the details of the object from the host.

    Requires the keys to be set (if any). After returning, new or changed properties from the host will be set on the instance.

    ## Returns

    A `NetAppResponse` object containing the details of the HTTP response.

    ## Raises

    `NetAppRestError`: If the API call returned a status code >= 400

  `def patch(self, hydrate: bool = False, poll: bool = True, poll_interval: typing.Union = None, poll_timeout: typing.Union = None, **kwargs) -> NetAppResponse`

    Updates the properties of an application.

    ### Overview

    Similar to creating an application, modification is done using the template properties of an application. The `storage_service`, `size`, and `igroup_name` of an application may be modified.

    ### `storage_service`

    Storage service modifications are processed in place, meaning that the storage can not be moved to a location with more performance headroom to accommodate the request. If the current backing storage of the application is in a location that can support increased performance, the QoS policies associated with the application will be modified to allow it. If not, an error will be returned. A storage service modification to a lower tier of performance is always allowed, but the reverse modification may not be supported if the cluster is over provisioned and the cluster is unlikely to be able to fulfil the original storage service.

    ### `size`

    Size modifications are processed in a variety of ways depending on the type of application. For NAS applications, volumes are grown or new volumes are added. For SAN applications, LUNs are grown, new LUNs are added to existing volumes, or new LUNs are added to new volumes. If new storage elements are created, they can be found using the `GET /application/applications/{application.uuid}/components` interface. The creation time of each storage object is included, and the newly created objects will use the same naming scheme as the previous objects. Resize follows the best practices associated with the type of application being expanded. Reducing the size of an application is not supported.

    ### `igroup_name`

    Modification of the igroup name allows an entire application to be mapped from one initiator group to another. Data access will be interrupted as the LUNs are unmapped from the original igroup and remapped to the new one.

    ### Application state

    During a modification, the `state` property of the application updates to indicate `modifying`. In `modifying` state, statistics are not available and Snapshot copy operations are not allowed. If the modification fails, it is possible for the application to be left in an inconsistent state, with the underlying ONTAP storage elements not matching across a component. When this occurs, the application is left in the `modifying` state until the command is either retried and succeeds or a call to restore the original state is successful.

    ### Examples

    1. Change the storage service of the database of the Oracle application to extreme and resize the redo logs to 100GB. `{ "oracle_on_nfs": { "db": { "storage_service": { "name": "extreme" } }, "redo_log": { "size": "100GB" } } }`
    2. Change the storage service, size, and igroup of a generic application by component name. `{ "san": { "application_components": [ { "name": "component1", "storage_service": { "name": "value" } }, { "name": "component2", "size": "200GB" }, { "name": "component3", "igroup_name": "igroup5" } ] } }`

    ### Learn more

    - `DOC /application`
    - `Asynchronous operations`

    Send the difference in the object's state to the host as a modification request.

    Calculates the difference in the object's state since the last time we interacted with the host and sends this in the request body.

    ## Args

    `hydrate`
      If set to True, after the response is received from the call, a a GET call will be made to refresh all fields of the object.
    `poll`
      If set to True, the call will not return until the asynchronous job on the host has completed. Has no effect if the host did not return a job response.
    `poll_interval`
      If the operation returns a job, this specifies how often to query the job for updates.
    `poll_timeout`
      If the operation returns a job, this specifies how long to continue monitoring the job's status for completion.
    `**kwargs`
      Any key/value pairs passed will normally be sent as query parameters to the host. If any of these pairs are parameters that are sent as formdata then only parameters of that type will be accepted and all others will be discarded.

    ## Returns

    A `NetAppResponse` object containing the details of the HTTP response.

    ## Raises

    `NetAppRestError`: If the API call returned a status code >= 400

  `def post(self, hydrate: bool = False, poll: bool = True, poll_interval: typing.Union = None, poll_timeout: typing.Union = None, **kwargs) -> NetAppResponse`

    Creates an application.

    ### Template properties

    The application APIs appear to be complex and long in this documentation because we document every possible template, of which there are currently 14. When creating an application, only a single template is used, so it is best to focus only on the template of interest. Other than the properties for the chosen template, only the `name` and `svm` of the application must be provided. The following three sections provided guidelines on using the properties of the templates, but the whole idea behind the templates is to automatically follow the best practices of the given application, so the only way to determine the exact list of required properties and default values is to dig in to the model section of the template. The templates are all top level properties of the application object with names matching the values returned by `GET /application/templates`.

    ### Required properties

    - `svm.uuid` or `svm.name` - The existing SVM in which to create the application.
    - `name` - The name for the application.
    - `<template>` - Properties for one template must be provided. In general, the following properties are required, however the naming of these may vary slightly from template to template.
    - `name` - The generic templates require names for the components of the application. Other templates name the components automatically.
    - `size` - This generally refers to the size of an application component, which may be spread across multiple underlying storage objects (volumes, LUNs, etc…).
    - One of the following must be specified:
      - `nfs_access` or an identifier (name or id) of an existing `export-policy`.
      - `cifs_access`
      - `igroup_name`
    - `os_type` - All SAN applications require an os_type to be specified in some way. Some templates refer to this as the `hypervisor`.

    ### Recommended optional properties

    - `<template>` - The following properties are available in some templates.
    - `new_igroups.*` - SAN applications can use existing initiator groups or create new ones. When creating new initiator groups, `new_igroups.name` is required and the other properties may be used to fully specify the new initiator group.

    ### Default property values

    If not specified in POST, the follow default property values are assigned. It is recommended that most of these properties be provided explicitly rather than relying upon the defaults. The defaults are intended to make it as easy as possible to provision and connect to an application. * `template.name` - Defaults to match the `<template>` provided. If specified, the value of this property must match the provided template properties. * `<template>` - The majority of template properties have default values. The defaults may vary from template to template. See the model of each template for complete details. In general the following patterns are common across all template properties. The location of these properties varies from template to template. * `storage_service.name` - value * `protection_type.local_rpo` - hourly (Hourly Snapshot copies) * `protection_type.remote_rpo` - none (Not MetroCluster) * `new_igroups.os_type` - Defaults to match the `os_type` provided for the application, but may need to be provided explicitly when using virtualization.

    ### Optional components

    A common pattern across many templates are objects that are optional, but once any property in the object is specified, other properties within the object become required. Many applications have optional components. For example, provisioning a database without a component to store the logs is supported. If the properties related to the logs are omitted, no storage will be provisioned for logs. But when the additional component is desired, the size is required. Specifying any other property of a component without specifying the size is not supported. In the model of each template, the required components are indicated with a red '*'. When a `size` property is listed as optional, that means the component itself is optional, and the size should be specified to include that component in the application.

    ### POST body examples

    1. Create a generic SAN application that exposes four LUNs to an existing initiator group, igroup_1.
       `{ "name": "app1", "svm": { "name": "svm1" }, "san": { "os_type": "linux", "application_components": [ { "name": "component1", "total_size": "10GB", "lun_count": 4, "igroup_name": "igroup_1" } ] } }`
    2. Create an SQL application that can be accessed via initiator iqn.2017-01.com.example:foo from a new initiator group, igroup_2.
       `{ "name": "app2", "svm": { "name": "svm1" }, "sql_on_san": { "db": { "size": "5GB" }, "log": { "size": "1GB" }, "temp_db": { "size": "2GB" }, "igroup_name": "igroup_2", "new_igroups": [ { "name": "igroup_2", "initiators": [ "iqn.2017-01.com.example:foo" ] } ] } }`
    3. The following body creates the exact same SQL application, but manually provides all the defaults that were excluded from the previous call. Note: The model of a sql_on_san application documents all these default values.
       `{ "name": "app3", "svm": { "name": "svm1" }, "template": { "name": "sql_on_san" }, "sql_on_san": { "os_type": "windows_2008", "server_cores_count": 8, "db": { "size": "5GB", "storage_service": { "name": "value" } }, "log": { "size": "1GB", "storage_service": { "name": "value" } }, "temp_db": { "size": "2GB", "storage_service": { "name": "value" } }, "igroup_name": "igroup_2", "new_igroups": [ { "name": "igroup_2", "protocol": "mixed", "os_type": "windows", "initiators": [ "iqn.a.new.initiator" ] } ], "protection_type": { "local_rpo": "none" } } }`

    ### Learn more

    - `DOC /application`
    - `Asynchronous operations`

    Send this object to the host as a creation request.

    ## Args

    `hydrate`
      If set to True, after the response is received from the call, a a GET call will be made to refresh all fields of the object.
    `poll`
      If set to True, the call will not return until the asynchronous job on the host has completed. Has no effect if the host did not return a job response.
    `poll_interval`
      If the operation returns a job, this specifies how often to query the job for updates.
    `poll_timeout`
      If the operation returns a job, this specifies how long to continue monitoring the job's status for completion.
    `**kwargs`
      Any key/value pairs passed will normally be sent as query parameters to the host. If any of these pairs are parameters that are sent as formdata then only parameters of that type will be accepted and all others will be discarded.

    ## Returns

    A `NetAppResponse` object containing the details of the HTTP response.

    ## Raises

    `NetAppRestError`: If the API call returned a status code >= 400

  ### Inherited members

  - `Resource`:
    - `from_dict`
    - `get_collection_url`
    - `get_connection`
    - `instance_location`
    - `path_keys`
    - `poll`
    - `set_connection`
    - `to_dict`
`class ApplicationSchema (*, only: typing.Union = None, exclude: typing.Union = (), many: bool = False, context: typing.Dict = None, load_only: typing.Union = (), dump_only: typing.Union = (), partial: typing.Union = False, unknown: str = None)`

  The fields of the Application object

  ### Ancestors

  - netapp_ontap.resource.ResourceSchema
  - marshmallow.schema.Schema
  - marshmallow.base.SchemaABC

  ### Class variables

  `creation_timestamp GET`

    The time when the application was created.

  `delete_data POST`

    Should application storage elements be deleted? An application is considered to use storage elements from a shared storage pool. Possible values are 'true' and 'false'. If the value is 'true', the application will be deleted in its entirety. If the value is 'false', the storage elements will be disassociated from the application and preserved. The application will then be deleted.

  `generation GET`

    The generation number of the application. This indicates which features are supported on the application. For example, generation 1 applications do not support Snapshot copies. Support for Snapshot copies was added at generation 2. Any future generation numbers and their feature set will be documented.

  `links GET POST PATCH`

    The links field of the application.

  `maxdata_on_san GET POST PATCH`

    The maxdata_on_san field of the application.

  `mongo_db_on_san GET POST PATCH`

    The mongo_db_on_san field of the application.

  `name GET POST`

    Application Name. This field is user supplied when the application is created.

  `nas GET POST PATCH`

    The nas field of the application.

  `nvme GET POST PATCH`

    The nvme field of the application.

  `oracle_on_nfs GET POST PATCH`

    The oracle_on_nfs field of the application.

  `oracle_on_san GET POST PATCH`

    The oracle_on_san field of the application.

  `oracle_rac_on_nfs GET POST PATCH`

    The oracle_rac_on_nfs field of the application.

  `oracle_rac_on_san GET POST PATCH`

    The oracle_rac_on_san field of the application.

  `protection_granularity GET`

    Protection granularity determines the scope of Snapshot copy operations for the application. Possible values are "application" and "component". If the value is "application", Snapshot copy operations are performed on the entire application. If the value is "component", Snapshot copy operations are performed separately on the application components.

    Valid choices:

    - application
    - component
  `rpo GET POST PATCH`

    The rpo field of the application.

  `s3_bucket GET POST PATCH`

    The s3_bucket field of the application.

  `san GET POST PATCH`

    The san field of the application.

  `smart_container GET POST`

    Identifies if this is a smart container or not.

  `sql_on_san GET POST PATCH`

    The sql_on_san field of the application.

  `sql_on_smb GET POST PATCH`

    The sql_on_smb field of the application.

  `state GET`

    The state of the application. For full functionality, applications must be in the online state. Other states indicate that the application is in a transient state and not all operations are supported.

    Valid choices:

    - creating
    - deleting
    - modifying
    - online
    - restoring
  `statistics GET POST PATCH`

    The statistics field of the application.

  `svm GET POST`

    The svm field of the application.

  `template GET POST PATCH`

    The template field of the application.

  `uuid GET`

    Application UUID. This field is generated when the application is created.

  `vdi_on_nas GET POST PATCH`

    The vdi_on_nas field of the application.

  `vdi_on_san GET POST PATCH`

    The vdi_on_san field of the application.

  `vsi_on_nas GET POST PATCH`

    The vsi_on_nas field of the application.

  `vsi_on_san GET POST PATCH`

    The vsi_on_san field of the application.