The AVEVA Adapter For Structured Data Files is supposed to be the successor to the PI Connector For UFL, but they work differently enough that each can handle certain types of files better than the other.
The AVEVA Adapter For Structured Data Files is good for CSV, XML, and JSON files whose data does not need to be manipulated before being archived.
The PI Connector For UFL is good for any format of text file that can be reliably broken up into chunks ("lines" in the most general sense) based on a list of text delimiters, and then those chunks are processed in order and your INI file code can be written so that the processing of earlier chunks affects the processing of later chunks. It isn't pretty for anything but CSV files, but the fact that the processing algorithm is so generalized yet customizable, combined with the fact that data from the file can be manipulated before using or archiving it, makes it surprisingly versatile. However, the PI Connector For UFL is no longer actively being worked on.
To make the migration from the PI Connector For UFL to the AVEVA Adapter For Structured Data Files more feasible, please allow the AVEVA Adapter For Structured Data Files to process files similarly to, or better than, the PI Connector For UFL. This could be done in a few ways:
The quickest and easiest way for AVEVA would be for the AVEVA Adapter For Structured Data Files to support the INI files that the PI Connector For UFL uses, perhaps with some minor adjustments, similar to the changes going from INI files for the PI Interface For UFL to INI files for the PI Connector For UFL. If AVEVA chooses this route, then the AVEVA Adapter For Structured Data Files should take the path to the INI file, rather than the contents of the INI file, as input to allow the INI file to be edited more easily. However, the INI file's syntax is more complicated than it needs to be, which leads me to my next point.
Create a functionally identical but more readable INI file format (the file extension does not need to remain "ini"). For example, instead of declaring variables as FIELD(1), FIELD(2), etc. and then stating their name, type, and format, all on different lines, you can instead ditch the FIELD numbers and syntax and just declare, on a single line, the name, type, and format of a variable. Similarly, instead of defining MSG(1), MSG(2), etc. and then defining those sections, you can instead ditch the MSG numbers and syntax and just have some syntax that allows those sections to be directly declared, and they can be processed in the order that they appear. However, there is an even better and possibly easier idea:
Allow the AVEVA Adapter For Structured Data Files to use existing query languages, beyond just XPath and JSONPath, that allow data to be manipulated. For example, Power Query in Excel and Power BI can handle all of the types of files that both the PI Connector For UFL and the AVEVA Adapter For Structured Data Files can handle, plus so much more, and any data can be transformed, replaced, removed, etc. However, currently, to move data from Power Query tables in Excel to PI, you need to do some scripting to open the workbook in Excel, refresh the table, and export it as a CSV file, being careful to not rely on outdated or insecure technologies in the process. However, Power Query is just an example, and there are probably other query languages out there that work better, are less or not proprietary, and do not require the use of a large or paid program like Excel.
It is up to AVEVA on which route they want to take, and maybe AVEVA will choose a route that I did not list. The main thing is that, in the end, the AVEVA Adapter For Structured Data Files can process a much wider variety of text files than it currently can.
I will give an example of a type of file that I deal with that the AVEVA Adapter For Structured Data Files cannot handle.
I have XML files that give hourly forecasts for a given day. The date is stated once at the start of the file, and then each forecasted value is shown with a number for the hour (1 to 24). The format of the file is determined by the company that provides them, and due to their large customer base, they will not provide the same information in a custom format for any specific customer. The timestamp needs to be derived from the information in the file. You need to take the date at the start of the file and combine it with the hour value, minus 1 hour. The AVEVA Adapter For Structured Data Files cannot do any of this.
If I insisted on using the AVEVA Adapter For Structured Data Files, then I would need to process the XML file in some other way and feed, to the AVEVA Adapter, a different file that it can actually handle, probably just a CSV file at that point. However, it is much easier to just use the PI Connector For UFL instead. I don't want to bypass using either of these 2 programs entirely because I want the benefits of buffering, logging, and failover without having to reinvent the wheel in a script or custom program, which is just too complicated for this case.