• Upload the files from the files store to the VFS. PTC provides the SAS URL for this VFS after Windchill+ deployment.

• Invoke customization code to identify and read files available in VFS and create corresponding objects in Windchill. This customization code utilizes the Windchill supported APIs and is submitted through CCD.

• Run the following command (for Linux) to copy the IntegrationsExample sample to /opt/ptc.

• Change the working directory to $WT_HOME/bin/customizationTools.

• Use ant to compile, deploy, and load data.

• A folder named Parent-Folder-<timestamp> is created in VFS and the sample files are added to this folder.

• A document is created in the ACME product for each sample file in VFS. You can view these documents by logging in as acmeorgadmin.

• In case of .txt files in VFS, the files are updated with sample text and the file name is appended with _updated.txt in the file name.

• A zip file named WTDocs.zip is created in the same folder using the primary content of Windchill document.

• Using the container-level SAS URL for the VFS, verify that all files excluding _updated.txt and WTDocs.zip are deleted from VFS.

• Ephemeral Storage: The VFS serves as temporary storage, like a temporary folder for customization code. It is recommended to delete the content or files from the VFS after utilization.

• Automatic Deletion: VFS contents or files are automatically deleted after 7 days. Once deleted, they cannot be recovered. Customization code should utilize and preferably delete VFS contents proactively within this 7-day window.

• Backup and Restoration: Since VFS is ephemeral storage, its contents or files are not backed up. Which means:

◦ If a system backup is taken on day 1, and new files (count N) are added to the VFS, utilized by the customization code, and subsequently deleted.

◦ Then, if the entire system is restored to the snapshot from day 1, then the N files that were added, consumed, and deleted will need to be uploaded, consumed, and deleted again, if required.

• Isolated Environments: Each Windchill+ environment has its own isolated VFS. Consequently, in cases of multiple Windchill+ deployments, when a CCD package is deployed in environment E1 and then promoted to environment E2, the customization code within that CCD package should be designed to operate independently of the specific VFS contents, as the contents in VFS can be different for different Windchill environments.

• For rehosting and promotion, by default, contents in VFS from source or staging environment will not be available. Ensure that the contents or files are available in VFS before the relevant customization code is invoked.

• During migration from Windchill on-premises to Windchill Plus or within Windchill Plus environments (Dev to QA or QA to Prod), VFS contents will not be available by default. Therefore, any customization that uses contents in VFS will fail. After a successful migration, upload the contents or files to VFS and then subsequently use VFS capability via customization.

• IO operations where Windchill and Azure Blob Storage are in different regions significantly slow down throughput compared to when both are in the same region.

• Content created by Windchill customization and written to VFS is verified up to a size of 1GB.

• Using VFS APIs, a zip file of size 3.84GB with 142103 entries is created successfully in 59 minutes when the Windchill and the storage account are in same region.

• Concurrency:

◦ Multiple threads can concurrently read from VFS.

◦ Writing to a zip file should be single threaded.

• Resiliency:

◦ If an error occurs while adding entries to a zip file, its integrity cannot be guaranteed. Additionally, the zip file format does not support editing entries once they are written. Therefore, a mechanism should be in place to retry multiple times in case of an exception while writing a file in VFS, with short breaks of a few seconds or minutes between attempts.