@srini NULL and empty are two different things and need to handled in two different ways. NULL indicates there is no value set, while EMPTY means a value of type new line, carriage return, tab, or space has been set as the value. There are a number of NiFi Expression language functions that work with non-exist attributes and attributes with either null or empty values. First question to ask is whether every FlowFile has both the branch and grade attributes? If some are missing the attributes, different handling needs to be done. If you don't know for sure that every FlowFile will have these attributes created, I suggest using the "isEmpty" NiFi expression language function to check. The "isEmpty" function will return true if the attributes does not exist, exist containing no value or exist containing only new line, carriage return, tab, or space. The UpdateAttribute has an "Advanced" UI that allows you to create if/then type functions. So With the above rules applied, all FlowFile leaving this UpdateAttribute processor will have both the "branch" and "grade" attributes. Those attributes will either have some previously assigned non-empty value or the "nobranch" and/or "nograde" values assigned to them. This works even if the incoming FlowFile was missing these attributes. Thanks, Matt ... View more

@Michael Rivera NiFi is designed to accept many triggers words sec, second, secs, seconds, min, minutes, mins, hr, hrs , day, days, etc.... The max it will accept as of NiFi 1.x is week or weeks (or wk or wks). If you enter an invalid trigger word, the processor will let you know it is invalid. Such as trying to use month or year will produce the below: Keep in mind that by using the "timer driven" scheduling strategy you are not setting a specific execution time. You are setting an execution interval where the first interval is scheduled upon start of the processor. The second execution will occur x amount of configured "run schedule" later. If you stop and then start the processor again, the interval starts over. The "CRON Driven" scheduling strategy allow you to configure an exact time(s) for execution. Thanks, Matt ... View more

@Adda Fuentes Since you started your new node with a configured authorizers.xml file pointing at a legacy authorized-users.xml file, the users.xml and authorizations.xml files in NiFi 1.1 where generated from that rather then inheriting those files form your already running cluster. Clear out the setting in your new nodes authorizers.xml file, remove the users.xml and authorizations.xml files, remove the flow.xml.gz file and restart this new node. It should successfully obtain these files from your existing cluster at this point. You will need to do one additional step once this new node has joined your cluster. Since the original clusters authorizations and users will not include this new node yet, you will need to access the cluster's UI from one of the original cluster nodes using and admin account and add the new node's DN as a user and then provide that new node with all the same access policies as the your existing node have. At a minimum you need to make sure your new node is granted the "Proxy user requests" access policy: If you do not do this the following issues could occur: 1. You will not be able to access the cluster's UI via the newly added node (you will get untrusted proxy message) 2. You will still be able to access the UI via the other nodes as long as NiFi does not switch the cluster coordinator to your newly added node. You cannot restrict NiFi from picking any node in your cluster to serve this role. Matt ... View more

@Anishkumar Valsalam NiFi supports three types of user authentication strategies: 1. SSL Certificates - This is the default authentication strategy and is always on. NiFi will always accept a user supplied SSL certificate in the connection before trying any other configured authentication strategy. If a SSL certificate is not presented in the connection, NiFi will close the connection unless another authentication strategy has been configured. Those other strategy must be configured and include: 2. LDAP - NiFi can be configured to fall back on this strategy which can be configured to connect to either LDAP or LDAPS. If your user use LDAP, they do not need to have user SSL certificates issued to them. If they do have SSL certificates loaded in their browser, NiFi will accept them and will not even try using LDAP to authenticate that user. 3. Kerberos - NiFi can be configured to fall back on this strategy. If they do have SSL certificates loaded in their browser, NiFi will accept them and will not even try using Kerberos to authenticate that user. Note: Alternate authentication strategies are configured in NiFi's login-identity-providers.xml file. NiFi SSL certificate authentication is the default (first strategy that is always attempted) and cannot be disabled. NiFi will only try one of the other authentication strategies (if configured) if SSL certificates are not presented for the user. Note: Only one alternative authentication Strategy can be configured. While SSL is always enabled, you can only add either LDAP or Kerberos, but not both. Note: Authentication is only step one or a two step process that needs to be successful before a user can successfully access NiFi. NiFi authorization occurs after successful authentication. User who can successfully authenticate via any one of the above authentication strategies still need to be authorized within NiFi for access to specific NiFi resources and components. Authorization of users requires adding those users to the configured authorizer and granted those added users access to whichever access policies are needed by that user. Thanks, Matt ... View more