@Bern  You just need to follow same steps you used in your original post question.   You drag the add process group icon to the canvas.: In the pop-up window select the "browse" icon to far right instead of entering a "Name": Navigate to and select your downloaded flow definition you created in Apache NiFi 1.13 (I would strongly encourage you to be using Apache NiFi 1.28). There have been many changes a fixes and you'll want to make sure your Apache NiFi 1.x dataflows are valid on the latest 1.28 before attempting to move them to Apache NiFi 2.x).  Apache NiFi 1.28 will also have deprecation logging that will help make user aware if they are using components that no longer exist in Apache NiFi 2.x.  You'll need to make modification to your flows so you are no longer using those components before moving your flow definitions over to NiFi 2.x.   Also be aware that NiFi 2.x no longer support NiFi Variables. These were deprecated and removed.  The replacement is NiFi Parameters.  So if you are using Variables in your NiFi 1 dataflows, you' need to modify your dataflows to use paramters before moving your flow definitons over to NiFi 2. After you have selected your flow definition json file, you have option to change name that is displays from json and click "Add": Remember that Apache NiFi 2.x is a major release change and the expectation is that you are on the latest NiFi 1.28 release before attempting to move to NiFi 2.  NOTE:  Cloudera Flow Management (CFM) licensed users have access to Cloudera specific automation tools that can auto transform templates into valid flow definitions and automated migration of CFM 2.1.7 SP2 (Apache NiFi 1.x based) flow.json.gz files into CFM 4.1x (Apache NiFi 2.x based) compatible version. This automation handles deprecated components, converting NiFi variables (deprecated) into NiFi parameters (replacement), etc. https://docs.cloudera.com/cfm/4.11.0/cfm-migration-tool/topics/cfm-mt-overview.html#concept_wlv_sl3_... Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@Bern  NiFi templates were deprecated in Apache NiFi 1.x and removed completely in Apache NiFi 2.x major release. Around Apache NiFi 1.12 the xml format was deprecated, but remained as a part or NiFi 1.x major release versions.  This impacted for both templates and the flow.xml.gz file that held everything you see on the canvas.  NiFi introduced Flow Definitions (template replacement which is in json format) and the flow.json.gz  to replace the flow.xml.gz for persisting the entire NiFi canvas's dataflows.  When you upgrade to a version of NiFi greater then 1.12, NiFi will still load from a flow.xml.gz file and will then convert and write back out the newer flow.json.gz format. Flow Definitions can be created by right clicking in a process group on the NiFi canvas and selecting option to download a flow definition for that specific process group. The screenshot you shared show you attempting to import a flow definition in Apache NiFi 2 but providing a NiFi template instead of a Flow Definition.  That is why you encountered the exception about it not being a valid json. Unfortunately, Apache NiFi does not have utility for converting NiFi templates into Flow Definitions.  So you will need to have a NiFi 1.13+ version of Apache NiFi where you can still load your templates and then download them as flow definitions )some templates will require manual modification before they can be downloaded as a flow definition.  There are numerous breaking changes in Apache NiFi 2.x major release so I suggest reading through the Apache NiFi migration guide to understand what those changes are any the manual actions you may need to make to your NiFi 1.x release flows before they can be used in NiFi 2.x. https://cwiki.apache.org/confluence/display/NIFI/Migration+Guidance NOTE:  Cloudera Flow Management (CFM) licensed users have access to Cloudera specific automation tools that can auto transform templates into valid flow definitions and automated migration of CFM 2.1.7 SP2 (Apache NiFi 1.x based) flow.json.gz files into CFM 4.1x (Apache NiFi 2.x based) compatible version. This automation handles deprecated components, converting NiFi variables (deprecated) into NiFi parameters (replacement), etc. https://docs.cloudera.com/cfm/4.11.0/cfm-migration-tool/topics/cfm-mt-overview.html#concept_wlv_sl3_5gb Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@zzzz77  Apache NiFi use to be by default unsecured when launched without setting up security manually.  The expectation was that the end user of Apache NiFi would take steps to secure the NiFi before using it for production use cases to protect sensitive data.  More recently the Apache Community decided to have NiFi Start securely out of the box. This was partly for two reasons.  First to avoid users from accidentally exposing sensitive information by have their NiFi running wide open to anyone who can access the url.  Secondly, most modern browser now force users to https://.... when an http://.. . address is supplied.   The out-of-the-box secure setup provides very minimal security.  It generates self-signed certificate so that TLS/SSL https can be used and it utilizes a new "Single User" authentication and "Single User Authorizer".     This single user authorizer give the generated single user full access to the NiFi.  There is no way to create additional users or modify authorizations when using this authorization provider.  It's intended use is to provide a secure NiFi out-of-the-box for ease of product evaluation.  For a more robust multi-user NiFi deployment different user authentication and Authorization provider need to be used.  Also recommend generating/obtaining properly signed certificates for your NiFi instance(s).   LDAP is probably the most commonly used for authentication through the "ldap-provider" since NiFi does not have a multi-user local provider option.  You can find  all authentication provider options in NiFi in teh admin guide under: User Authentication  With a change to the authentication provider, you will also need to setup a multi-user authorizer so you can manage the authorization for your ldap user identities.   You can find option in the admin guide under Multi-Tenant Authorization. Most common setup typically utilizes the Managed-Authorizer, File-Access-Policy-Provider, Composite-Configurable-User-Group-Provider, File-User-Group-Provider, and LDAP-User-Group-Provider. In your File-Access-Policy-Provider, you'll be able to define who your "initial admin" user will be.  This would typically be one of your ldap users.  This provider on first launch will generate a authorizations.xml file that will contain the minimum required authorization required for the admin user.  NOTE: the initial admin does not get access granted to everything; however, will have ability to granted all additional authorizations the admin user may want and to setup authorizations for all other users. The admin guide also covers the various authorization policies here: Configuring Users & Access Policies NiFi authorizations are very granular.  You can set unique policies for each user if you want.   EVERY user must be authorized for "view the user interface" or the user will not be able to access the UI.  The admin user can optionally create a different process group on the NiGi UI for each team or person that will be building dataflows on the canvas.  The Admin user then authorizes the team of person to the appropriate process group. This prevents one user/team form being able to view the configuration of another teams dataflow or modify another teams dataflows.  They will only have access within their authorized process group.   A user does not need to be an "Admin user" to build dataflows.   What makes a user an admin is someone who can modify all policies, modify users, etc.    Individual users can not modify authorizations or user and can still be granted ability to modify components so they can build dataflows within their admin authorized process group(s). NOTE: All user can see where all components are placed on canvas tp prevent one team from building on top of another; however, those components for which a user is not aithorized will appear with dashed outlines and no details. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt   ... View more

@Justinh_klik  Welcome to the community! Unfortunately, both the url you shared are truncated and I am unable to see what you are attempting. My initial thought would be to use a GenerateFlowFile processor sceduled based on a cron to run daily.   You can use NiFi Expression Language (NEL) to dynamically define Attributes on the FlowFile each time GenerateFlowFile is scheduled to execute for "since" and "until"  date strings you need to use in the URL used by the InvokeHTTP processor. The GenerateFlowFile  processor passes this daily generated FlowFile to the InvokeHTTP processor trigger its daily execution.   The "HTTP URL" property in the InvokeHTTP processor also support NEL.   Something like the following: https://api.pagerduty.com/oncalls?since=${since}&until=${until}&users&Schedule_ids... ${since} and ${until} within above URL would get replaced with the values assigned to the FlowFile attributes "since" and "until" that exist in the FlowFile being passed to the InvokeHTTP processor.   Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@ptrsz  Welcome to the community. The more detail you can provide, the better the community can assist. Are you trying to use the InvokeHTTP to return from the NiFi rest-api of the same NiFi instance where this NiFi sis running or accessing the rest-api of another NiFi instance? Is this a NiFi cluster or standalone NiFi instance? What version of Apache NiFi are you using (rest-api endpoint may differ by version)? What rest-api endpoint are you trying to use? Here is an example configuration using a secured Apache NiFi 2 instance to retrieve the NiFi system diagnostics data from the NiFi rest-api of the same Nif where the dataflow is running. Since NiFi is secured, the rest-api endpoint will require authentication and authorization.  The easiest way to set this up is to use a clientAuth certificate keystore for authentication.  So I setup a StandardRestrictedSSLContextService within the NiFi Process Group. I then configured my InvokeHTTP processor to use the above SSL Context service and configured the appropriate rest-api endpoint for the system diagnostics (https://<nifi-hostname>:<nifi-port>/nifi-api/system-diagnostics)   Next I need to make sure my clientAuth certificate DN user identity has been authorized for the "view system diagnostics" within the NiFi Policies; otherwise , you will encounter a 401 not authorized response:   Now when my invokeHTTP executes I get the json response from that rest-api endpoint with my diagnostic data:     Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more