Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


This is the proposal for the format Model Schema for the Event Message:

Code Block
titleEvent Message Schema
linenumberstrue



p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo}
p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; min-height: 13.0px}
span.s1 {font-variant-ligatures: no-common-ligatures}



swagger: "2.0"

info:

description: |

  This is the schema for the Operational Events common format

  for Control Loop operations.




operation_event_request:

  description: |

    This is the schema that describes Control Loop

    Operational Event requests that are published by the Policy

    Framework to ONAP Applications (eg. Controllers,

    Orchestrators, etc.) for performing operations in

    response to a Control Loop event detected by DCAE.

  properties:

    version:

      description: |

        This is the version for this Operation Event

        request format.

      type: string

    common:

      description: |

        This is a common header filled with information

        to assist with auditing and logging the event as

        it is processed by the various ONAP applications.

      required: true

      type: object

      $ref: "#/definitions/common"

    action:

      description: |

        This is the action that is to be performed by the

        ONAP Application.

      required: true

      type: string

    aai:

      description: |

        This identify the entity within A&AI Database in which

        the action is to be taken upon.

      required: true

      type: array

    payload:

      description: |

        An array of name/value pairs and arrays of name/value pairs

        that are required to assist the application during execution

        of the operation.

      required: false

      type: array




operation_event_response:

  description: |

    This is the schema that describes Control Loop

    Operational Event Responses that are published by

    ONAP Applications (eg. Controllers, Orchestrators, etc.) back

    to the Policy Framework in response to a Request.

  properties:

    version:

      description: |

        This is the version for this Operation Event Schema

        response format.

      type: string

    common:

      description: |

        This is a common header filled with information

        to assist with auditing and logging the event as

        it is processed by the various ONAP applications.

      required: true

      type: object

      $ref: "#/definitions/common"

    status:

      description: |

      required: true

      type: object

      $ref: "#/definitions/response"




definitions:

  common:

    timestamp:

      description: |

         UTC timestamp for when this message is sent. For auditing

         and logging purposes to help track the timing of Control

         Loop operational events.

      type: string

      required: true

    originator-id:

      description: |

        Unique identifier for the entity that is

        publishing this operational event. This is required in case there

        are multiple entities deployed to support scaling/resliency, the appropriate

        entity can direct the request/response back to the originator.

      type: string

      required: true

    request-id:

      description: |

        A unique ID that identifies the request for this Operation. The request should

        set this and all responses should copy this over exactly.

      type: string

      required: true

    sub-request-id:

      description: |

        A unique ID that further identifies the request for this Operation

        in the case of retries for a specific operation. The request should set

        this value and all responses should copy this over exactly.

      type: string

      required: true

    timeout:

      description: |
      type: string
      required: true

  response:
    status:
      description: |
        The response status for the operation. Upon receiving a requeset, the
        response should send ACCEPTED, ERROR or REJECTED.

        ACCEPTED the application has accepted the operation and has begun working on it.

        REJECTED the application has rejected the operation.

        Once an ACCEPTED response is published, the application must follow up with a
        response of SUCCESS or FAILURE on the operation.
      type: string
      values: { "ACCEPTED", "REJECTED", "SUCCESS", "FAILURE" }
    message:
      description: |
        For ACCEPTED and SUCCESS, this field is optional to add a mesage to.

        For REJECTED and FAILURE, this field must indicate a human-readable message as to
        why it was rejected or failed.
      type: string
      required: false