[00:00] In this lesson, we will talk about Tag imports and exports. In some cases, you may need to backup your tags. So you want to make some large scale changes to a particular tag provider, it might be a good idea to backup your tags. You can always take a gateway backup which will backup your entire gateway, including your tags. However, gateway restores require the gateway service to be stopped temporarily. A tag import can be performed while the gateway is running without the need for any downtime. Tag exports and imports are facilitated from the tag browser and your designer, you simply need to select the tag or tag folders you want to export. In my case, I want to export my entire tag provider so I will select all my tags like so. I'll click on the kebab drop down list here and select Export tags. You will get a little save window where you will be prompted to select your file save location, we support two types of tag exports, XML and JSON. I will leave the default JSON file option and press the Save button to save my export to my desired location. I will then get a small pop up telling me that my save succeeded. If you want it to export your tags as XML, we can select our tags once more, head to the tag explorer button. Or alternatively, you can simply right click and select Export tags and simply change our files extension from JSON to XML like so. I can then press Save to save my tags in my desired location in XML format. So you wanted to import some of your tag exports, you first need to select whatever location you want your tags to be imported into, in your tag browser. Always be mindful of where you import your tags. If I select my query tags folder and go through the import process using one of my tag exports we took a few seconds ago, I will have essentially imported my entire tag provider into the query tags folder which may not be ideal. So it is important to be cautious when importing tags. If I do not select a location at all and choose to import tags, all my tags will be imported into the location in my tag browser. This is exactly what I want. So I will simply click on the kebab drop down menu and select Import tags. You will see a warning explaining to you that no folder or UDT definition was selected. And you will be asked if you want to import tags to the root. We do. So I will click Yes. A window will open prompting us to select the tag export file we wish to import. You will note that down below under files of type the CSV is supported. This is mostly for legacy purposes. The Legacy CSV format in older versions of ignition does not include alarm configurations in the export file. So we prefer to use XML or JSON. Now, you'll want to be aware of the collision policy in the right hand side here. Basically, when we are importing tags, how should admission handle any sort of path collisions that exist during an import. With Abort you will get an error message at the end like so. This error is telling me Hey, the tags you're importing already exists, I will abort the import. Now if you did not want the error message to appear, we can close it, try our import once more and set the collision policy to ignore. This way, if there is any type of collision conflict it just skips it and moves on without the error message. Let's open up one of these export files. I have both of the files here on my file explorer. I will right click on the JSON file and select to open it using notepad plus plus, you can of course use a text editor of your choice. Once the file opens, I will see all of my tags arranged in a large JSON object, having my tags laid out in front of me in a text editor will give me flexibility. I will be able to make mass edits to large number of tags using the Find and Replace tool without having to manually make any changes using the tag browser which can be slow and painful. The designer does have its own Find and Replace tool which can be reached pressing Ctrl + F or Command + F. And it does allow you to search for tags and do some Find and Replace. But sometimes it's nice to do that in an external editor of some sort. So again, I could try editing one of these export files you could always do a find and replace, say you needed to update the name of the device connection or you needed to change the datatype of a whole bunch of your tags, you could just export the entire tag provider, make the change, save the file and import your modified tags back into your system. Now, best practices go, this one's kind of common sense. If you're going to do any sort of external editing of these export files, it's usually a good idea to save those changes in a separate file. So that way you have an export of your tag provider before you made any modifications. From my tag export here, I will do something simple like change the folder name, my derived tags folder I will modify it to be called derived tags new and I will save my changes if I try and import these tags now. Notice how a new folder is created and named derived tags new. If I open it, you will notice that contents match exactly what is in the derived tags folder. The import will not delete the derived tags folder or overwrite with the derived tags New Folder. Both will remain. So when you're working with these export files and you import, if there isn't a tag on a specific node, we don't delete nodes. We don't delete folders or other tags. We can however overwrite them if we choose an overwrite collision policy. Let's open up our tag export and see how this will look like. I will change my derived tags New Folder back to its original name, I will scroll down to my OPC tags, and I will change it to point to a different OPC device. I cheated a little bit since both device connections are pointing to the same simulator, the only real thing I have to change is the device name and the rest of the OPC Item Path will remain the same. I will save my changes and try to import these tags using the overwrite collision policy. After having done so, if I drill into my tags configuration, I see that my old OPC tag's OPC Item Path was overwritten by the new OPC Item Path and therefore my OPC tags are not pointing to a different OPC device. The renamed collision policy will simply rename any node that is flagged as having collided with an existing node. I will try and import my entire tag provider over itself using the renamed collision policy. Notice how every single one of my nodes was duplicated and renamed. This is quite messy now. Instead of deleting nodes one by one, I would just delete all of them and re import them using one of my original backups to get me back into my original state. The last collision policy rule, Merge Overwrite, we did not talk about much but it's similar to the overwrite option. The only difference is that the overwrite option completely overwrites colliding nodes and their entire configuration. The merge overwrite will keep all the existing node configurations unless one of them conflict in which case it will overwrite just the colliding configuration.