@leandrolinof  Understand that NiFi wraps all ingested content in to a NiFi FlowFile.  A NiFi FlowFile consists of FlowFile meatdata/attributes (key/value pairs written to the flowfile_repository. NiFi processors can be used to add and modify existing FlowFile Attributes) and FlowFile content (bytes written to a claim within the NiFi content_repository).  Since NiFi is data format agnostic, the FlowFile model allows NiFi to ingest any data format.  This does not mean that NiFi can read/edit all data formats. It is the responsibility of an individual processor that must be designed/coded to operate against specific data types. While NiFi does not have a purpose built processor specifically for reading PDF, It does ship with scripting processors that can be used to execute custom script code that can extract content from a PDF in to FlowFile attributes. Reference example: https://gist.github.com/mattyb149/48e72a26d0f62f330e30 https://stackoverflow.com/questions/55169492/nifi-extract-from-pdf-to-text I assume since that directory contains multiple PDF, each of those PDF have a unique name? Once you have ingested your PDFs, the above example groovy script may allow you to create attributes on your FlowFile which you can use later via NiFi Expression Language statements to dynamically set configuration properties on the putEmail processor uniquely by FlowFile it executes upon. When you look a processor's documentation for each configuration property, you will see if it supports NiFi Expression language and to what extent it is supported Supports Expression Language: true (will be evaluated using flow file attributes) Example above states NiFi Expression language is supported and you can use FlowFile attributes which would come from each FlowFile that processor is executing against. If you can extract the needed text from each PDF in to additional attributes on each FlowFile (one FlowFile created for each PDF ingested) with buyer name, then you can use those to dynamically define properties per FlowFile in the PutEmail processor. If you desire is to consume every PDF only once, you should be using the ListFile --> FetchFile processors.  The ListFile can be configured to maintain state so that the same FlowFiles are not listed more than once. (ListFile must be configured for "primary node" execution only in a multi-node NiFi cluster setup to avoid data duplication). The message body of an email is going to expect that message to ASCII text. The "Content Type" property of the PutEmail processor is expected to be set to the content' mime type (for a PDF file the mime.type would be "application/pdf"); however, i suspect the putEmail processor may have issue with that mime.type.  If that is the case, you'll need to send you PDF as attachments to the email only. I am not sure what the "buyer's ID" gets you.  Is that buyer's ID in the PDF filename?  How does the buyer's ID get you the buyer's email address to which you will send the PDF via PutEmail? to answer you question about is it possible, I believe so.  It is about collecting/creating the needed metadata/attributes from 1 or more sources and adding them to your FlowFile with the PDF content needed to successfully send your email. I hope above gets you moving along that path.  NiFi offers so many components, there is often more than one may to solve a use case.  First step is laying out a step by step processor for how you would solve this use case outside NiFi manually and then translate each of those steps in to automated NiFi dataflow.  Then you can narrow down to the specific step in that use case where help is needed further. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more

@leandrolinof  I am having trouble understanding your query clearly. The PutEmail processor ONLY supports talking the content of the source FlowFIle and adding it as the email message or adding it as an attachment to the email.  The putEmail processor is not involved at all with how the content was added or modified in the source FlowFile that comes from the upstream ExecuteSQL processor. So what exactly are you trying to pass through the PutEmail processor?  The BASE64_ENCODE you are retrieving from Oracle?  You can write that to a FlowFile attribute.  The "Message" configuration property of the PutEmail processor, as well as many others, support using NiFi Expression Language (NEL).  That means you could read from the FlowFiles attributes anything you have placed there and insert it into the email message body. If you can provide more detail it may be helpful.  It sounds like you want to send an email with aPDF file attachment, but sounds like you haven't even ingested the PDF into NiFi yet. Thank you, Matt ... View more

@myzard  If you are positive the username and password entered are valid, this likely points to an issue in your login-identity-providers.xml ldap-provider configuration with the manager DN and/or manager password. Since this is an xml file, the first question to ask is if the password contains any XML special characters (<, >, ", `, or &): < replace with &lt; > replace with &gt; " replace with &quot; ˋ replace with &apos; & replace with &amp; If so, you'll need to escape them by using above substitutions. Next is to use ldapsearch to verify the manager DN and manager password works using same configuration set in the ldap-provider (minus xml substitutions if any) against the same username and password. Make sure the results from your ldapsearch on returns one matching user. I have seen setups where ldap had same username multiple times under different DNs. This will not work with NiFi login as NiFi would be unable to determine which is the actual user being authenticated.  In this scenario, adjust your search base so that it only returns one user entry. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped.   Thank you, Matt ... View more

@Olwe  How is zabbix authenticating it self with your NiFi?  When NiFi is secured, all clients must be authenticated and authorized.   An HTTP 401 means the client was not authorized. NiFi does not use sessions.  So when a user logs in via a username and password, if the authentication was successful, a bearer token is issued for the user for that specific NiFi node.   That bearer token will remain valid for the duration configured in your NiFi login provider or until the logout endpoint is invoked.  The client is expected to include that bearer token in all subsequent requests.  If you hit a NiFi rest-api endpoint like .../nifi-api/flow/cluster/summary without a bearer token or a client certificate, the client will be treated as "anonymous" and not authorized.   You should see this unauthorized endpoint request logged in the nifi-user.log.  When you access rest-api endpoints via the browser which you used to login, the browser takes care of including the bearer token.  I am not familiar with Zabbix, but same requirements exist (get bearer token and include bearer token in future rest-api calls) For example, obtaining a token using a login provider: curl 'https://<nifi-hostname>:<nifi-port>/nifi-api/access/token' \ --data-raw 'username=<username>&password=<password>' \ --compressed \ --insecure Above will return the <bearer token>. Then you would use that bearer token in your future rest-api requests: curl 'https://<nifi-hostname>:<nifi-port>/nifi-api/flow/cluster/summary' \ -H 'Authorization: Bearer <bearer token>' \ --compressed \ --insecure   If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped.   Thank you, Matt ... View more

@emaxwell  A few suggested additions to this excellent article: 1. The keystore password is not required to list the keystore via the keytool command.  When prompted for a password, you can just hit "enter" without entering a password.  The password would be needed if you want to export the actual privateCertEntry from the keystore which is not necessary in this procedure. 2. The ldap-provider configured in the login-identity-providers.xml file has two options for how to identify the authenticated ldap user: <property name="Identity Strategy">USE_DN</property> Above will use the full Distinguished Name (DN) as you mention in the article. <property name="Identity Strategy">USE_USERNAME</property>  Above will use the string entered by user at the login window as the user identity. 3. Identity mapping properties in the nifi.properties file have three properties: nifi.security.identity.mapping.pattern.<unique string>=<Java regex> nifi.security.identity.mapping.value.<unique string>=<Resulting string when java regex matches, Java Regex capture groups can be used here> nifi.security.identity.mapping.transform.<unique string>=<NONE, LOWER, UPPER> The <unique string> can be anything but must be same exact string for all three properties.  Also patterns are checked in alphanumeric order against the identity strings. First matching pattern has its value and transform applied. So you want to make sure the more complex patterns come first to avoid having wrong pattern's value and transform being applied.  So a pattern like "^(.*)$" should definitely come last. The "transform" property allows you to apply an all uppercase, all lowercase, or no transform to the resulting value string. Thanks, Matt ... View more

@ajignacio  User and group identity strings much match identically. Your ldap-user-group-provider is syncing users and groups by the identity string found in the CN AD attribute.  This is why you are seeing only the CN username and CN groupname strings in the users UI within NiFi. However, when you are logging in to NiFi to authenticate you user via the ldap-provider, the resulting user identity sting is the users full AD Distinguished Name (DN).  NiFi treats different strings as different users. The  ldap-provider can be changed to use the user identity string typed in the username field instead of using the full DN.  This is done by changing the following property: <property name="Identity Strategy">USE_DN</property> change it to : <property name="Identity Strategy">USE_USERNAME</property> Upon successful authentication the resulting user identity is evaluated against any identity mapping patterns that may be configured in the nifi.properties file.  The resulting mapped value is then passed to the configured authorizer (managed-authorizer in your setup).  There the authorizers is looking up that user identity string (case sensitive) against the user strings synced by your configured users group providers.  If an exact match is found both the user string and the now learned group string(s) are checked against the configured NiFi policies to determine authorization. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped.   Thank you, Matt     ... View more

@yongki  "Remote" state should only be configured in the tailFile processor when the directory containing the file being tailed is mounted on every node in the NiFi cluster (meaning the flow running on each NiFi cluster node has access to the exact same file being tailed).  If it is a shared directory/file, then the tailFile must also be configured to execute on "Primary node" only. Matt ... View more

@VJ_0082  Since your log is being generated on a remote server, You will need to use a processor that can remotely connect to the exteranl server to retrieve that log Possible designs: 1. The could incorporate a FetchSFTP processor in to your existing flow.  I assume your existing RouteOnAttriibute processor is checking for when an error happens with your script?  If so, add the FetchSFTP processor between this processor and your PutEmail processor.   Configured the FetchSFTP processor (configured with "Completion Strategy" of DELETE) fetch the specific log file created.  This dataflow assumes the log's filename is always the same. 2. This second flow could be built using the ListSFTP (configured with filename filter) --> FetchSFTP --> any processors you want to use to manipulate log --> PutEmail. The ListSFTP processor would be configured to execute on "primary" node and be configured with a "File Filter Regex".  When your 5 minute flow runs and if it encounters an exception resulting in the creation of the log file, this listSFTP processor will see that file and list it (0 byte FlowFile).  That FlowFile will have all the FlowFile attributes needed for the FetchSFTP processor (configured with "Completion Strategy" of DELETE) to fetch the log which is added to the content of the existing FlowFile.  If you do not need to extract from or modify that content, your next processor could just be the PutFile processor. If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post. Thank you, Matt   ... View more