No bulletins on any of the processors. All of the output flow-files have 0 bytes and the error 401 in the attributes. All of the properties look correct and I can copy the values from the non-working to the manually created processor and it works fine. When you export the SSL context service and re-import it you have to reset the password on the trust store and that is the only change I am making.
I will need to dig into the nifi logs to check for any errors there. On Thu, Jun 8, 2017 at 11:24 AM, Matt Gilman <[email protected]> wrote: > Raymond, > > When it's in a state that is not working are there any bulletins on the > second processor? When it's in that state and you view the configuration > details for that processor, do the properties look correct and the same as > when you manually re-add the processor through the UI? Specifically, I'm > wondering about the SSL Context Service since you mentioned fixing that > after an export/import process resolves the issue. > > Any other issues in the logs/nifi-app.log or the logs/nifi-user.log? > > Thanks > > Matt > > On Thu, Jun 8, 2017 at 11:59 AM, Raymond Rogers <[email protected]> > wrote: > >> We have a node.js service that automatically creates & manages NiFi >> groups using the REST API which works great in NiFi 1.1.1. We are >> upgrading our NiFi instances to 1.2.0 and I have found that some of the >> processors are exhibiting odd behavior. >> >> We have a flow the connects to the Outlook 365 OWA service generates an >> access token and then uses that token in two different InvokeHTTP >> processors. The first processor always works and the second always returns >> an HTTP error 401. >> >> If I delete and manually re-add the InvokeHTTP processor with the same >> configuration it always works. >> >> If I export this flow from the NiFi web interface and then re-import it, >> only fixing the SSL context service, it works every time. >> >> Using our node.js service to create the exact same flow in NiFi 1.1.1 it >> always works. >> >> Thanks, >> Raymond >> > >
