Discovered discrepancies between MEF and YAML documents

[jesmanlangit]

Hi @MichalLaczynskiAmartus !

Happy new year!

We found some discrepancies in the MEF and the yaml document (Fergie version). Could you clarify them?

1. We couldn't find the fields parameters in the product - inventory API documentation despite its existence in the YAML file. Would you know whether which reference doc is acurrate?
2. In MEF 115 doc, the specified endpoint is "/declineQuote," whereas in the YAML file - quoteManagement.api, the endpoint is listed as /rejectQuote. Can you confirm which information is correct?
3. In the GET /trackingRecord and GET /trackingRecord/{id} under MEF W143. Tracking Records are used to track actions performed on entities like Performance Monitoring Profile, Performance Monitoring Job, and Performance Monitoring Report.
   However, for the 'GET /trackingRecord' API, there is no corresponding POST API, and no example response is provided. Some attributes like 'relatedObjectId', 'request', 'user', and 'system' are not defined in the documentation. In addition, the responses of Performance Job, Profile, or Report do not carry the 'relatedObjectId' attribute. This causes problems in associating the report from the create performance monitoring profile because of the absence of the id. Is this the expected framework or are we supposed to expect to use an id for these APIs?

[MichalLaczynskiAmartus]

Hi @jesmanlangit

Thank you very much for the feedback.

1. This one is already spotted and will be fixed in the next possible version (Haley or Irene). Using fields in the request is not an MEF-used pattern, it's not in other APIs, so the best approach is to ignore it.
2. Point taken. The action name was renamed during the course of the project. The endpoint name might not have been changed due to backward compatibility reasons. I will take it to the project and ask for action. For now - use as in the yaml file, as this is what others are also implementing.
3. I will forward the question to the MEF W143 editor @bartoszm

[jesmanlangit]

Hi @MichalLaczynskiAmartus - the URL links to Grace version, we're currently following Fergie version. Wouldn't this be a conflict?

[MichalLaczynskiAmartus]

Here's the fergie varsion. I do not think there was any change.
https://github.com/MEF-GIT/MEF-LSO-Legato-SDK/blob/fergie/documentation/serviceApi/pm/MEF%20W143%20-%20LSO%20Allegro%2C%20LSO%20Interlude%20and%20LSO%20Legato%20Performance%20Monitoring%20Profiles%2C%20Jobs%2C%20Passive%20Statistics%2C%20Notifications%20and%20Collections%20API%20-%20Developer%20Guide.md#72416-type-trackingrecord

[jesmanlangit]

Hi @MichalLaczynskiAmartus - thank you so much that answers my question! However, we have a couple of follow ups.

Problem statement: id field in the tracking record is not present in performance job, profile and report. So when calling the GET tracking record {id} endpoint, there's no tracking record id that can be used because it's not existing on the performance profile, job and report APIs.

Our developers suggested to add a tracking record id field on said APIs and use that to assign a tracking record id for the created performance profile, job and report records.

Any thoughts on this? Perhaps we misunderstood the workflow.

[jesmanlangit]

In addition, this is the same problem for request and system fields.

[MichalLaczynskiAmartus]

As stated in 133.1 attribute description:
"A list of tracking records. Tracking records allow the tracking of modifi-cations to the PM Profile. The track-ing records should not be embedded in the PM Profile to allow retrieving the PM Profile without the tracking records."
Tracking Record beind a heavyweight object is by design not attached to the object it keeps track of.
To get the list of TR per given object - just ask a GET with relatedObjectID to all the list at once.

regarding the system and request fields - They are part of TracingRecors, so they are not addressable individually. We may think to add it to _Find version of TR to allow a single API call to retrieve all and full tracking records for give object.

Would that solve your concern?

[jesmanlangit]

Thanks @MichalLaczynskiAmartus! Looking forward to the rest of the answers.

[jesmanlangit]

Hi @MichalLaczynskiAmartus - adding one more clarification from the Interlude side.

We noticed that the performanceReport doesn't hold the performancejob.id in the request which refrains us from associating the created performance job > performanceReport > /listener/performanceJobReportReadyEvent > /listener/performanceJobReportPreparationErrorEvent.

Our idea is to add the performancejob.id parameter in the performanceReport API to link the mentioned APIs.

Wanted to consult if this is a good approach from your purview or do you have any other suggestion. Asking because this approach entails to deviating from the published MEF standard API and might have an unknown impact.

Thanks in advanced.

[jesmanlangit]

Any feedback here @MichalLaczynskiAmartus ?

[MichalLaczynskiAmartus]

Hi @jesmanlangit

performanceReport does not have a direct performancejob.id. It has the attribute performanceJob of type PerformanceJobRefOrValue. If you use ref, then you provide an id of the Job. But you can also provide a Job by Value, in which case there is no actual PeformanceJob object created to refer to.

[jesmanlangit]

Hi @MichalLaczynskiAmartus - does this mean that an identifier relationship is not essential for these endpoints?

[MichalLaczynskiAmartus]

I am saying that there are 2 ways to request a report. Either with creating a job, or by providing the job configuration directly. This is the "RefOrValue" pattern.

[jesmanlangit]

Thanks @MichalLaczynskiAmartus ! Appreciate the help, truly.