Decoding of file xids

[RafaelZincke]

Hi all,

I am trying to identify the paths of files loaded to Connect. If I take a file xid and decode it with a base64 decoder I get another id or something:

The file xid is linked to the following path in Connect:

If I e.g. go one step above (the folder where the file is located) and decode the string, I at least see the fileshare where it is located.

I thought that the new string after decoding is an id and checked the data but could not find anything attached to it. 

Is there a different decoding/encoding for files than for e.g. the SQL data sources? For the SQL database the base64 decoder works perfectly.

Thank you!

Best regards,

Rafael

[PetrH · Accepted solution]

Hi @RafaelZincke , 

The files has the XID encoding composed slightly different way than database objects.

Looking to configuration of file sync job (load-alteryx-fs) section for files... 

I see that file object xid is coded from system_name/parent_hash

So from files XID you cant easily decode the file name.

Fot the folder above it would be similar 

$lu.toXidEncoded("${system_name}/${parent_hash}") 

 for some database hierarchy ecoding we use something like this..

#set($xidParams="${catalog_engine}/${catalog_environment}/${catalog_name}/${schema_name}/${table_name}")

The idea behind is quite simple, with databases and the lineage between workflow, report and database table we needed to implement some level of abstract of detail, when some piece down in row might be missing, but still the lineage might be in some cases established.

Most typically the lenght of db hierarchy string is not so long - which keeps the XID quite short.

With the files we usually have the full object name, but we need also to represent its hierarchy in shared folder. Typicallu the files are nested deeper in tree, using long names for folders, so its not quite optimal to construct XIDS out of full hierarchy which can full UNC path provide. The lenght of connect URL having this long xid might be problem for browsers.

FYI some time later in development process we have introduces some XID shortening in app feature to deal with longer xids (I belive xids longer than 200 chars) than being somehow compressed, so even for database objets its not work for ALL, but suits most customer use cases. Only small amount of XIDS actually are in database world longer than 200, however with files and some folder hierarchy its easy to reach 200.

So thats why..

for research on how we construct XIDS see the resp. section in different sync job(loading job) config files. See your connect URL plus "/acadmin/menu/config_files" and navigate to tab loading to see different configs for, load-alteryx-db for databases, fs for file systems, wf for workflows. tableau, salesforce and powerbi.

hope it explains the XID coding.

have a great day

Petr