Response of /v1/provide-list-of-network-element-interfaces-on-path-in-generic-representation is having empty consequent action list

[Ziabatcha]

Load: v1.0.1h_impl
API:
POST "http://XXXXX:XXXX/v1/provide-list-of-network-element-interfaces-on-path-in-generic-representation"

Request Body:
{
"input-value-list": [
{
"field-name": "TargetMacAddress",
"field-value": "00:B0:AC:05:75:C9"
}
]
}

Response:
{
"consequent-action-list": [],
"response-value-list": [
{
"value": "513250009:LTP-MNGT",
"datatype": "string",
"field-name": "listOfNetworkElementInterfacesOnPath"
}
]
}

[Ziabatcha]

Do we need to pass this consequent list in request body?

[latta-siae]

To be check why consequent list is empty.
Response format is passing api rules

[latta-siae]

In the file "load.json" there isn't any consequence action list associated on "v1/provide-list-of-network-element-interfaces-on-path-in-generic-representation"

Action Profiles associated:

• 'matr-1-0-2-action-p-000' -->

                {
                    "uuid": "matr-1-0-2-action-p-000",
                    "profile-name": "action-profile-1-0:PROFILE_NAME_TYPE_ACTION_PROFILE",
                    "action-profile-1-0:action-profile-pac": {
                        "action-profile-capability": {
                            "operation-name": "/v1/start-application-in-generic-representation",
                            "label": "Inform about Application",
                            "input-value-list": [],
                            "display-in-new-browser-window": false
                        },
                        "action-profile-configuration": {
                            "consequent-operation-reference": "/core-model-1-4:control-construct/logical-termination-point=matr-1-0-2-op-s-bs-002/layer-protocol=0/operation-server-interface-1-0:operation-server-interface-pac/operation-server-interface-capability/operation-name"
                        }
                    }
                },

• 'matr-1-0-2-action-p-001' -->

                {
                    "uuid": "matr-1-0-2-action-p-001",
                    "profile-name": "action-profile-1-0:PROFILE_NAME_TYPE_ACTION_PROFILE",
                    "action-profile-1-0:action-profile-pac": {
                        "action-profile-capability": {
                            "operation-name": "/v1/inform-about-application-in-generic-representation",
                            "label": "Release History",
                            "input-value-list": [],
                            "display-in-new-browser-window": false
                        },
                        "action-profile-configuration": {
                            "consequent-operation-reference": "/core-model-1-4:control-construct/logical-termination-point=matr-1-0-2-op-s-bs-004/layer-protocol=0/operation-server-interface-1-0:operation-server-interface-pac/operation-server-interface-capability/operation-name"
                        }
                    }
                },

• 'matr-1-0-2-action-p-002' -->

                {
                    "uuid": "matr-1-0-2-action-p-002",
                    "profile-name": "action-profile-1-0:PROFILE_NAME_TYPE_ACTION_PROFILE",
                    "action-profile-1-0:action-profile-pac": {
                        "action-profile-capability": {
                            "operation-name": "/v1/inform-about-application-in-generic-representation",
                            "label": "API Documentation",
                            "input-value-list": [],
                            "display-in-new-browser-window": true
                        },
                        "action-profile-configuration": {
                            "consequent-operation-reference": "/core-model-1-4:control-construct/logical-termination-point=matr-1-0-2-op-s-bs-005/layer-protocol=0/operation-server-interface-1-0:operation-server-interface-pac/operation-server-interface-capability/operation-name"
                        }
                    }
                },

• 'matr-1-0-2-action-p-003'-->

{
                    "uuid": "matr-1-0-2-action-p-003",
                    "profile-name": "action-profile-1-0:PROFILE_NAME_TYPE_ACTION_PROFILE",
                    "action-profile-1-0:action-profile-pac": {
                        "action-profile-capability": {
                            "operation-name": "/v1/start-application-in-generic-representation",
                            "label": "List network element interfaces on path to target network element",
                            "input-value-list": [
                                {
                                    "field-name": "TargetMacAddress"
                                }
                            ],
                            "display-in-new-browser-window": false
                        },
                        "action-profile-configuration": {
                            "consequent-operation-reference": "/core-model-1-4:control-construct/logical-termination-point=matr-1-0-2-op-s-is-004/layer-protocol=0/operation-server-interface-1-0:operation-server-interface-pac/operation-server-interface-capability/operation-name"
                        }
                    }
                }

[latta-siae]

Hi @kurzkama could please help me on this issue.
I didn't found in the spec the associated action for "/v1/provide-list-of-network-element-interfaces-on-path-in-generic-representation"
so then consequent action list result empty

[kmohr-soprasteria]

To me this looks like this should be handled in the same way as in '/v1/inform-about-release-history-in-generic-representation':
There we don't have any action profileInstances, just GenericResponseProfiles (1 per release version):

And in the OAS we have the following (shortened):

  /v1/inform-about-release-history-in-generic-representation:
    parameters:
        ...
    post:
      operationId: informAboutReleaseHistoryInGenericRepresentation
      summary: "Returns release history for generic representation"
      tags:
        - BasicServices
      responses:
        "200":
          description: "Release history provided"
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/genericRepresentation"
                example:
                  response-value-list:
                    - field-name: "1.0.0"
                      value: "20.11.2010 - Initial version."
                      datatype: "string"
                  consequent-action-list:
          headers:
          ...
        default:
          $ref: "#/components/responses/responseForErroredServiceRequests"

There are also no related action profileInstances (consequent-action-list in example is also empty).
So to me it looks like the references to actionProfile instances in the schema definition of "#/components/schemas/genericRepresentation" are ignored here.

I'm not familiar with how those services work internally.
Maybe someone from TechM (Prathiba, Iswaryaa) team can confirm, if my assumptions are correct.

[IswaryaaS]

Hi Katharina,

• I can understand from Response of /v1/provide-list-of-network-element-interfaces-on-path-in-generic-representation is having empty consequent action list #305 (comment), the testing team is asking if the request-body shall contain consequent-action-list in it. It is not necessary as the request doesn't need it as per schema definition and i agree with the decision made on Correct requestBody example of /v1/provide-list-of-network-element-interfaces-on-path-in-generic-representation #323.
• Coming to the response-body, the response should be populated based on the presence of profile instances.
  Here, as we could see the service /v1/provide-list-of-network-element-interfaces-on-path-in-generic-representation only has response-p instance (matr-1-0-2-response-p-015), presence of "response-value-list" is only expected. The "consequent-action-list" field could be an empty array.
• I agree with Response of /v1/provide-list-of-network-element-interfaces-on-path-in-generic-representation is having empty consequent action list #305 (comment), that the implementation is similar to /v1/inform-about-release-history-in-generic-representation except the value to be calculated from Elasticsearch.

[kmohr-soprasteria]

@latta-siae: please implement in a similar fashion as /v1/inform-about-release-history-in-generic-representation

[latta-siae]

Hi @kmohr-soprasteria, @IswaryaaS

if I understood well, if there isn't any actions profile associate, API response should omit the value like:

Response:

{
	"response-value-list": [
		{
			"value": "513250009:LTP-MNGT",
			"datatype": "string",
			"field-name": "listOfNetworkElementInterfacesOnPath"
		}
	]
}

[kmohr-soprasteria]

@lorenzo: Please discuss this with TechM team. I'm not familiar with implementation of /v1/inform-about-release-history-in-generic-representation