Exporting from LST
When exporting from an LST schedule file:
A new LST schedule file in the LST version 12 format (with header) is produced, regardless if the processed schedule file is LST version 11, LST version 12 or a headless file.
The original, processed schedule file will remain untouched.
The new schedule file will be named either
(Direct Export ) original_name.exportedLST12.LST
or(Merge Export) original_name.exportedmergedLST12.LST
The new schedule is placed in the folder specified in Channel Settings.
The export process happens after every imported/updated schedule file.
Direct Export
Performing a Direct Export produces a schedule file containing every event present in the channel.
This includes:
Events imported from the processed schedule file.
This includes Message Events introduced due to missing Page, Action or PDE.Events added by Rules.
(At update) Events that were previously there, regardless of origin, such as manually added events or events added by the import/update of a previous schedule file.
A new header is created for the exported schedule file. The header includes only the identifier for LST version 12, nothing else.
Merge Export
When performing a Merge Export:
A schedule file is produced containing every event in the processed schedule file merged with the events added by Rules after the import/update process.
The events added by Rules do not necessarily mean they were added during the import/update of the processed schedule file.
If events added by Rules were already previously present, those might or might not be merged into the processed schedule file.If an event added by Rules is not under a Primary Event contained in the processed schedule file, the event will be skipped from being merged, as an event that is missing a Primary Event parent can not be merged.
Events merged are placed under the Primary Event that they belong to, in the binary of the exported schedule file.
LST version:
If the processed schedule file is LST version 12, then the header is preserved for the exported schedule file.
If the processed schedule file is LST version 11, then a new header will be created in the same way as it is done in Direct Export.
Export Characteristics
Metadata Loss
In the case of an event being imported as a Message Event due to a missing Page, Action or PDE, its metadata will not be preserved as metadata for Message Events is not saved.
This means that the event, when exported, will not contain any metadata information that it might have had in the original schedule file.
Exported Data too large for LST Structure
Due to size limitations of an LST structure for event data, event data exceeding LST structure limits will be truncated with the maximum possible information being saved.
For example, for an event containing a description larger than 32 bytes (the maximum size), only exports the first 32 bytes.
Exported Event Description
The page name of exported events will have the value of its description, as the reverse happens during the import process. This is not noticeable when exporting an event imported by an LST schedule file, as both description and page name will already have the same value, but is noticeable when exporting an event added by different means. If the page name does not match the description, then the page name will be lost in the export process.
Universal Sercom Driver
If an imported event has its Trigger Id and/or Description value replaced due to the usage of Universal Sercom Driver, then this process will be reverted during the export process. To achieve this, the original value for Trigger Id and Description are saved in metadata during the import process.
Note: This is only possible if metadata is preserved. Not every event type supports metadata.
LST Version 11 to 12 Conversion
As the exported schedule file will always be in LST version 12, a processed LST version 11 schedule file will be converted to LST version 12 during the merge export process.
Note: This conversion process is not required for Direct export.
The conversion process attempts mapping of data from a v11 structure to a v12 structure in the best way it can:
New data only available in v12 will be left empty.
Dynamic data will be combined with their respective fields.
For example, ExtendedId will be combined with Id, and so on.