Migrating variables using flow definition JSON as input
Learn how to use the Cloudera Flow Management Migration Tool to convert
variables to parameters and parameter contexts from flow definition JSON files.
Example flows for migrating variables
The following NiFi flow demonstrates both variable and component migration.
It shows how variables are used within process groups and how they are referenced by
individual components.
Flow definition file:
TCP_Listener_flow_definition.json
This file contains the TCP Listener process group (ID:
b41940d7-0194-1000-42fc-458834630567)
TCP Listener Process Group
This process group contains the following simple flow:
The process group defines a variable called TCP
Listener Port, which is referenced by the ListenTCPRecord processor.
The example guides you through the variable migration process and shows how
to maintain a clear activity log. Although the example uses a simple flow, the
step-by-step approach can be applied to more complex scenarios. In real-world
scenarios, Cloudera recommends defining a migration strategy based on the structure
of each flow. In some cases, individual flow definition migration may not be
necessary.
Copy the TCP_Listener_flow_definition.json file to the Migration
Tool’s input folder (/etc/migration-tool-input).
Run Stage 1 variable migration on
TCP_Listener_flow_definition.json, using the following
command.
Log of all actions performed during this stage
of the migration.
The following changes were made during the
variable migration:
A new parameter context was created with a
new parameter called TCP Listener Port, which
replaces the corresponding variable.
The TCP Listener Port variable was removed.
migrated_TCP_Listener.json
A modified flow definition, which is not
compatible with NiFi 2 yet.
It contains everything the original flow
definition did, except the TCP Listener process group
now references a parameter instead of the removed
variable.
This is still a NiFi 1 flow definition, so do
not load this file directly into NiFi 2. Use an empty
NiFi 1 instance to review the modification made by the
tool. The flow definition will appear unchanged, but
variables will be replaced with parameters of the same
name, which are now referenced by the processor
instead.
Changes in the syntax: Variables were
previously referenced using ${}, whereas parameters are
now referenced using #{}.
NiFi 1
variables: ${variable_name}
NiFi 2 parameters:
#{parameter_name}
Validate the Stage 1 variable migration output for the
TCP_Listener_flow_definition.json.
Check the new flow definition in a NiFi 1 instance to verify that the
flow matches your expectations.
Start your NiFi instance.
Create a new process group.
Load
sourceVersion/migrated_output/migrated_TCP_Listener.json
to NiFi 1.
Remove the ‘migrated_‘ prefix from the process
group name.
Confirm that variables were correctly converted to
parameters.
Review the activity_log.json file and check for
any manual-change-requests or
manual-validation-requests.
If there are manual-change-requests or
manual-validation-requests to handle, follow these
steps:
Make the modifications on the NiFi canvas,
indicated by the manual-change-requests or
manual-validation-requests in the
sourceVersion/activity_log.json.
Right-click on the TCPListener process group.
Select Download flow definition without
external services.
Save the file as migrated_TCP_Listener.json and
overwrite the one in the
sourceVersion/migrated_output folder.
If no requests are present in the log, proceed to the next step.
At this stage, the flow definition no longer contains variables and uses
parameters instead. If the flow meets your expectations, you can either run
a full variable migration to validate your flow in NiFi 2 or proceed with
migrating the components.
Run full variable migration (Stage 1 and 2) on
TCP_Listener_flow_definition.json.
Move migrated_TCP_Listener.json from Step 2 into
the input folder (/etc/migration-tool-input) and
rename it to TCP_Listener_flow_definition.json for
clarity.
Make a backup of the output folder
(/etc/migration-tool-output/variables) before
running the next migration step.
The contents of the previously generated
sourceVersion folder will be overwritten, but this
is not a concern as the tool generates the same sourceVersion output as
before.
Additionally, a targetVersion directory is
created, containing the output files of the Stage 2 part of the
migration.
migrated_TCP_Listener.json
NiFi 2-compatible flow definition in terms of
variables
You can load it into NiFi 2 and validate it
activity_log.json
List of all actions performed during this stage
of the migration
Proceed with component migration using the input folder from step 3.