Migrating components using a template without variables

Learn how to use the Cloudera Flow Management Migration Tool to migrate components from template.xml files that do not contain variables. Component migration with template.xml input can only be used if the flow does not contain any variables. If the template contains variables, follow the Migrate components using template with variables section.

Example flow for migrating components

The following NiFi flow is used to demonstrate both variable and component migration.

There is one template.xml file:

TCP_Listener_template.xml
The file consists of the process group TCP Listener (ID: b41940d7-0194-1000-42fc-458834630567).

TCP Listener Process Group

This process group contains the following simple flow:

The ListenTCPRecord processor does not reference any variables.

The example guides you through component migration and maintaining a clear activity log. While this example template is simple, the step-by-step approach shows how this method improves clarity for more complex migrations. In real-world scenarios, you have to define a migration strategy based on your flow’s structure.

Copy the TCP_Listener_template.xml file to the /etc/migration-tool-input folder.

This is a template without any variables.
Run Stage 1 component migration on the TCP_Listener_template.xml file using the following command.
```
bin/migration.sh nifi migrate-components \
-i /etc/migration-tool-input/TCP_Listener_template.xml \
-od /etc/migration-tool-output/components \
--sourceCompatibleOutput
```
This generates a sourceVersion folder that contains the output files of the Stage 1 migration.
```
components
└── sourceVersion
    ├── activity_log.json
    └── migrated_output
        └── migrated_TCP_Listener_template.json
```
activity_log.json
- The log describes all the actions that were performed for this stage of the process group migration.
- Log of all actions performed during this stage of the process group migration.
migrated_TCP_Listener_template.json
- A modified NiFi 1 flow, which is not compatible with NiFi 2 yet.
- It contains everything the original flow did, except the TCP Listener process group was modified as described in the Activity Log.
Validate the Stage 1 component migration output for TCP_Listener_flow_definition.json.
1. Load the migrated_TCP_Listener_template.json into a NiFi 1 instance and check the flow.
2. Review the activity_log.json file and check for any manual-change-requests or manual-validation-requests. If none are present, proceed to the next step.
  In this example, you can see the following information in the Activity Log:
```
{
	"sequence" : 2,
	"type" : "change-info",
	"subject" : "b41966ad-0194-1000-a08d-a92489457356",
	"message" : "Component [org.apache.nifi.processors.standard.ListenTCPRecord] has been deprecated (NIFI-13509)",
	"context" : {
  	"rule" : "36227b60-75f0-40dc-8caf-a2ec577aa54c"
}
```
  Search for the value of the “subject” element using the NiFi search box.
  This will locate the ListenTCPRecord processor. No manual modifications are needed at this point. However, note that the ListenTCPRecord processor is deprecated and not available in NiFi 2. After completing both stages of the component migration process, follow-up instructions outline how to address this deprecation.
3. If manual changes are necessary, update the migrated_TCP_Listener_template.json on the NiFi canvas after loading it. Once the flow is validated and meets expectations, continue with the next step.
Run full component migration (Stage 1 and 2) for TCP_Listener_template.json.
1. Copy the migrated_TCP_Listener_template.json file and rename migrated_TCP_Listener_template.json to TCP_Listener_template.json for clarity.
2. Make a backup of the output folder (/etc/migration-tool-output/components) before running the next migration step.
  
  note
  step is crucial because the same output folder is used as in the previous migration, and its contents will be overwritten. To retain a record of changes made at each stage, it is better to create a backup.
3. Run the full component migration using the following command.
```
bin/migration.sh nifi migrate-components \
-i /etc/migration-tool-input/TCP_Listener_template.json \
-od /etc/migration-tool-output/components
```
  This generates the following output:
```
components
├── sourceVersion
│   ├── activity_log.json
│   └── migrated_output
│	└── migrated_TCP_Listener_template.json
└── targetVersion
    ├── activity_log.json
    └── migrated_output
	└── migrated_TCP_Listener_template.json
```
  The contents of the previously generated sourceVersion folder will be overwritten. The contents represent the NiFi 1-compatible version of the migrated flow. Since the root process group only contained the two process groups on which you already performed Stage 1 component migration, the activity log will only include the same entries as those in Steps 2 and 4.
  
  Additionally, a targetVersion directory is created, containing the output files of the Stage 2 part of the migration:
  migrated_TCP_Listener_template.json
  NiFi 2-compatible flow 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, and any manual steps that you need to perform.
Validate the Stage 2 component migration output for TCP_Listener_flow_definition.json.
1. Load the targetVersion/migrated_output/migrated_TCP_Listener_template.json into a NiFi 2 instance and check the flow.
2. Review the targetVersion/activity_log.json file.
  In this example, you can see the following manual-change-request entry.
```
{
	"sequence" : 6,
	"type" : "manual-change-request",
	"subject" : "b41966ad-0194-1000-a08d-a92489457356",
	"message" : "The component has been deprecated. It is suggested to replace it with a combination of [org.apache.nifi.processors.standard.ListenTCP] and [org.apache.nifi.processors.standard.ConvertRecord] processors",
	"context" : {
  	"rule" : "36227b60-75f0-40dc-8caf-a2ec577aa54c"
}
```
  1. To identify the processor affected by these changes, search for the value of the “subject” element in NiFi’s search box.
    
    It refers to the ListenTCPRecord processor.
  2. Open the TCP Listener process group.
    
    You can see that the processor is marked with dashed borders and its version number still shows that of the NiFi 1 instance. It means that it is a "ghost processor", not available in NiFi 2. The log message suggests replacing it with a combination of ListenTCP and ConvertRecord processors.
  3. Instantiate and configure the ListenTCP and ConvertRecord processors, connect them appropriately, and then remove the ghost processor.
    
    Besides these changes there are no further manual-change-requests or manual-validation-requests in the Activity Log.
3. Download the flow definition and you have the fully NiFi 2 compatible TCP_Listener_template.json.