@Justee  The ExecuteProcess [1] processor by design does not allow an inbound connection. It is designed to create an output FlowFile and does not except a FlowFile as input. You can connect getFile to the ExecuteStreamCommand [2] processor [1] https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-standard-nar/1.13.2/org.apache.nifi.processors.standard.ExecuteProcess/index.html [2] https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-standard-nar/1.13.2/org.apache.nifi.processors.standard.ExecuteStreamCommand/index.html   ... View more

@Justee  Not really sure what you mean by "combine".  Can you elaborate on your use case? You can drag a connection from GetFile to either ExecuteProcess or ExecuteStreamCommand, but is suspect that is not what you are asking here. Thank you, Matt ... View more

@Rupesh_Raghani  NiFi was not designed to provide a completely blank canvas to each user.  There are important design reason for this. NiFi runs within a single JVM.  All dataflows created on the canvas run as the NiFi service user and not as the user who is logged in.  This means that all user's dataflows share and compete for the same system resources.  Another user's poorly designed dataflow(s) can have an impact on the operation of another user's dataflow(s).  So it is important for one users to be able to identify where backlogs may be forming even if that is occurring in another user's dataflow(s).   With a secured NiFi, authorization policy control what a successfully authenticated user can see and do on the NiFi canvas.  While components added to the canvas will always be visible to all users, what is displayed on the component is limited only stats for unauthorized users (no component names, component types, component configurations, etc).   So an unauthorized user would be unable to see how that unauthorized component is being used and for what.  The unauthorized user would also not have access to modify the component, access FlowFiles that traversed those components (unless that data passed through an authorized component somewhere else in the dataflow(s)), etc. Besides resource usage, another reason users need to see these place holders for all components is so that users do not build dataflows atop one another.  It is common for multiple teams to be authorized to work within the same NiFi.  It is also common to have some users who are members of more than one team.  For those users, it would be very difficult to use the UI if each teams flows were built on top of one another.   Most common setup involves an admin user creating a single Process Group (PG) on the root canvas level (top level - what you see when you first log in to a new NiFi).  Then each team is authorized only to their assigned PG.  So team1 user logs in and there PG is fully rendered and non authorized PGs are present by non configurable and no displayed details.  team1 is unable to add components to canvas at this level and must enter their authorized PG before they can start building dataflows.  When you enter sub-PG, you have a blank canvas to work with. Hope this helps with your query. Matt ... View more

@midee  This use case is really not clear to me. The image you shared is the content of a single FlowFile and that content has numerous "customfield_" fields with most being "null" and one having a string value. So you are asking that this 1 FlowFile with both null and non-null "customfield_" fields is routed to the path A because at least one "customfield_" field as a non-null string?  The content would remain unedited. And you want other FlowFiles where the content contains nothing but all "customfield_" fields with null value routed to path B?  The content would remain unedited. Thanks, Matt ... View more

@myuintelli2021  Let's start with your mapping pattern setup here: nifi.security.identity.mapping.pattern.dn=^CN=(.*?), OU=(.*?)$ nifi.security.identity.mapping.value.dn=$1 nifi.security.identity.mapping.transform.dn=LOWER    You node hostnames look like this: CN=nifi4.{valid_domain}.com, OU=NIFI So if we ran your hostname against the pattern Java Regular expression we would see: Capture group 1 (.*?) would match on nifi4.{valid_domain}.com Capture group 2 (.*?) would match on NIFI  Then the value $1 used is only what came from capture group 1, so the string that would get passed to the NiFi authorizer would be nifi4.{valid_domain}.com You log output does reflect this now: 2021-06-08 15:33:19,173 WARN [NiFi Web Server-15] o.a.n.w.s.NiFiAuthenticationFilter Rejecting access to web api: Untrusted proxy nifi3.{valid_domain}.com The problem you have is that your file-user-group-provider is still using the full DN when setting up your clients and policies for your nodes: <property name="Initial User Identity 2">CN=nifi2.{valid_domain}.com</property> <property name="Initial User Identity 3">CN=nifi3.{valid_domain}.com</property> <property name="Initial User Identity 4">CN=nifi4.{valid_domain}.com</property> Above lines should be now: <property name="Initial User Identity 2">nifi2.{valid_domain}.com</property> <property name="Initial User Identity 3">nifi3.{valid_domain}.com</property> <property name="Initial User Identity 4">nifi4.{valid_domain}.com</property> AND in the file-acces-policy-provider: <property name="Node Identity 1">CN=nifi2.{valid_domain}.com</property> <property name="Node Identity 2">CN=nifi3.{valid_domain}.com</property> <property name="Node Identity 3">CN=nifi4.{valid_domain}.com</property> Above needs to change to: <property name="Node Identity 1">nifi2.{valid_domain}.com</property> <property name="Node Identity 2">nifi3.{valid_domain}.com</property> <property name="Node Identity 3">nifi4.{valid_domain}.com</property>   You will need to remove the users.xml and authorizations.xml files again, so that they get recreated on NiFi startup after making these changes. Thank you, Matt ... View more