Enhance GetOIDForPath to include more descriptive errors

[lucasmoten]

The following error can be reported when NiFi communicates with the endpoint

There was an error hitting the /config endpoint of GM Data: java.lang.Throwable: There was an error with a call to GM Data: 

It's unclear whether the root of the error is

• Incorrect certificate
• Incorrect trust
• if the error is in the call to /config or the call to /self (I dont have insight into the server logs)

We need to make this more verbose to aid in diagnostics.

[ghost]

@lucasmoten From the error message you can see that it is an error with the call to the /config endpoint. The error message in the circumstance above takes the response from GM Data as is - in this instance GM Data did not return any message with their error response which creates the semi-confusing message above. The only thing I could do to clarify this situation from the processor's end is to detect empty messages and display a generic message such as "GM Data did not return a reason for this error response"

[lucasmoten]

In this processor there is a call to both /config and /self showing up on the server.

Is the order of that /self then /config?

If so, then the next thing to put here is the actual error from the stack. The existing message implies there is something after "There was an error with a call to GM Data: " If there is no message, then there's at least other information (status code is showing as 403 in the server logs) that would be helpful. Ultimately, I'm trying to ascertain whether the actual cause is due to trust failure in setting up the communication, an expired user certificate, or an unauthorized user certificate.

If the order is /config, then /self, then the above applies, as well as consideration to change the error message to indicate that its failing on /self instead of /config. However, regarding the 403, that is showing for both /config and /self, so it seems there may need to be two error messages?

[ghost]

@lucasmoten The order is /config then /self. https://github.com/greymatter-io/nifi-sdk/blob/e2b28004fa728d433a59913930819c8c667c05d9/gmd-sdk/nifi-data-processors/src/main/scala/com/deciphernow/greymatter/data/nifi/processors/utils/GetOidForPathStreamingFunctions.scala#L36 is the line where it failed. In that same function the processor makes both the call to /config and the call to /self as neither depends on the other to work. Directly after these calls it attempts to get information from both, starting with the response from /config. If there is some error with the call to /config it short circuits and attempts to log any error response given from GM Data, then moves onto the next flowfile.

[lucasmoten]

Was merged in Friday September 18 via PR #17. That has since been published as a a Release 1.0.1. Closing