NIFI-1941: Child group contents in exported templates

[mcgilman]

• Ensuring child group contents are included in exported templates.

[jvwing]

Reviewing

[jvwing]

I ran through the following steps to test this fix:

1. Confirm the bug
   a. Built a template on master/1.0 branch with a process group
   b. Exported the template
   c. Confirmed that process group content was not in the exported XML file
   d. Confirmed that template could not be imported into a different NiFi (it imports into the same NiFi OK, because the IDs match?)
2. Verify the fix
   a. Exported the same template using the fix code
   b. Verified that the exported XML contained the process groups
   c. Verified that the template can be imported into a second NiFi
   d. Verified that the template can be run in the second NiFi

Everything worked great up to step 2d, running the imported template in the second NiFi. After CTRL-A selecting everything and clicking Run, I got this nastygram: LocalPort[name=stuff to log,id=9c17cb62-4df3-4122-ab36-44f290dc2bce] is not a member of this Process Group

Which is a reference to an input port in a Process Group nested in a Process Group. Manually navigating around the flow and starting all of the components worked fine without errors. I get a similar error stopping the flow.

The id "9c17..." is not in the template XML file. From poking around at the API it does exist, it is the "stuff to log" input port as expected in my template. The parent-child relationships between Process Groups and Input Ports looked OK to the untrained eye. What make this weirder is that I get a comparable error on the original NiFi I exported the template from. So I'm not sure this is a problem specific to this fix.

TestNiFi1941FixTemplate.xml.txt
Matt, are you aware of this issue, and do you experience this importing and running the attached template?

[mcgilman]

@jvwing Thanks for jumping in to review! I am not aware of this specific issue though I know we have a number of outside JIRAs surrounding templates and the 1.0.0 release. It doesn't surprise me that the UUID is not in the serialized template as the component's generate new UUIDs upon instantiation. This allows us to drop the same template on the canvas as many times as we want to.

The issue you mentioned may even lay in some REST API changes for starting components. Want me to open a new JIRA to address this issue as it's outside the scope of the original?

[mcgilman]

@jvwing Actually, I think I see what the issue is. Going to verify my change and if all looks good, I'll update the PR.

[mcgilman]

@jvwing Just addressed the issue and rebased to current master. Thanks again for the thorough review. It was the components in that template 'for good measure' that caught the problem. :)

[jvwing]

Thanks for tracking that down, it makes sense now that I see your changes. I tested the new changes, did a full build with contrib check (thanks for the earlier fix), and will merge.