Why do we need some many hashed paths for the AppMeasurement.js

[thomas_amsler]

Due to legal reasons we cannot use the CDN to get our launch scripts. So we download the generated files with the archive option in the environment. This was always a bit cumbersome because the top level paths always changed with each build and the inner path with each version of the AnalyticsExtension.

So we had something like this:

/BLe4b698d19ee94cf8b785407ccb4b97b1/hostedLibFiles/EP23d75a37c9fa4adb8bac5e48782e354a/AppMeasurement.js

Today I'v built the library again for dev using the latest extension version and the path exploded to this:

/CO43553243d83145ca9145261e586d2a23/PRc77ae538547743d6a733621fe60bd876/BLd0c019fe63cc434fad86cb9a55e49dc1/hostedLibFiles/EPd2399f7c689a4ae38db44080f8c6e80b/AppMeasurement.js

I assume all these hashed path will change with every build. So we have a, sorry me french, shitload of work each time we update our launch scripts. As we cannot simply extract the zip to an apache, we need to upload it into a CMS (even AEM) and recreate all this folders anew.

And as a side issue, even Windows (maybe the integrated ZIP) complains with too long paths when I try to extract it somewhere deeper then than one level below the disk.

Is this really neccessary or can this please be changed back? I don't care about these folders if I am not using a CDN, so we wouldn't need any hash at all; except for maybe caching reasons, but the top one would be enough for that.

[Andrey_Osadchuk]

Hi Thomas,

Just out of curiosity, did I understand the major concern correctly that the folder structure can't be deleted and created automatically (e.g. by a script) in the CMS while unzipping the archive?

The top level path can be actually set is the Environment configuration in the "Self-hosted Path to Library" field. This will mean that the path you mentioned will be a subfolder. For example, you can set the self-hosted path to "/launch-folder/". Then all paths generated by Launch will be referring to it as a top path. So by unpacking the archive to /launch-folder/ you do not need to change anything else on the CMS level as I understand.

Let me know if I'm missing anything.

[thomas_amsler]

In AEM the only ZIP files that can be uploaded and unzipped automatically are so called content packages with a defined structure, I created an idea a while ago that they should provide an option to generate such an AEM compatible ZIP; it is the same company after all...

The top level path is ok that is working as expected, but is also a bit limitted as it is the path you define from where the script is loaded, but in AEM this is not the same as where the script is stored in JCR.

[thebenrobb]

Sorry, I'm not super familiar with AEM, but the first two hashed paths are your Company ID (CO1234) and Property ID (PR1234).  Those should never change.  The third is your Build ID (BL1234) and that will change each time you do a build.  The 4th is an Extension Package ID (EP1234) that will change whenever you upgraed your extension.

However the .zip package should also contain symlinks at the root level that link down to the main Launch Library.  That .zip package is designed so that you can reference the symlinks in your published HTML and never have to make individual changes for each build.

Also the Main Library will reference AppMeasurement when it needs it, can you explain a bit more about why you need to reference AppMeasurement directly?

[chadr69849887]

I'm having the same exact issue (with the same security concern).. Visual Studio 2017 and MSBuild don't like paths longer than 260 characters. So if I include these files as is, they take up 202 characters. Which doesn't leave much flexibility for the file location in windows. AKA, one developers computer may work, while another won't compile because of the character issue. (yes, there is a win 10 fix, and no...it didn't work for me, and yes, even if it did, we would need to get corporate IT to fix which would take forever).

So I see you are saying the folders matter, but I found that the actual launch-XXXX.min.js file that we needed was in 3 different locations within the archive. And that all three .min. files are identical. So instead of using the one at the root of the downloaded file, I just copied the files that were in the build folder into my site. I then had the two launch-XXX files (one min, one non-min), and two RC files. There was also a folder for hostedLibFiles which i copied directly. This reduced the character for the longest deepest file from 202 to 97. A much more manageable number.

At first this didn't work, but then I went into the launch and changed the path, removed the extra folders...and bam. It looks like it works. The files load properly and they seem to be firing correctly in Adobe Experience Cloud Debugger.

Now my question is, outside of this being a manual process to reduce the urls, if htis works, why can't it just be the standard? When you download to run local, just download the build folder? (with the correct paths). Or is this really not working, but just looks like it is?

[thomas_amsler]

I don't need to reference it directly, but the full path to it is configured in the launch script: hostedLibFilesBaseUrl

So we either have to change the generated file manually after downloading it or create a new folder (or move rather move the existing one) after each build.

I understand the hashes for company and property and even build for a CDN. But if you download it, it would be way easier to just have it flat, e.g. launch.js and AppMeasurement.js in the same root folder of the ZIP.

[thebenrobb]

I'll talk to Engineering about this.  A very similar problem came up in one of our Slack channels recently (may be the same issue actually).  Changing the structure of the Archive seems like it would be challenging for backward compatibility reasons, but maybe there's something we can do.

[thomas_amsler]

Maybe just add another option, e.g. "Flat Archive"

There you can add all the scripts to the ZIP without any folders and generate the path for this hostedLibFilesBaseUrl to only what you configure.

Or even create a new Adapter which only generates a flat zip to download...

[charlk79482207]

Has there been any update to this, we are facing the same issue.

We are pulling down the archive, deploying it via our build pipeline however fails due to the folder character limit.. Have a look at the `hostedLibFilesBaseUrl` and you will see how unreasonably long the path is.

We could automate the replacing the paths if we had some reference to the keys used for naming the folders.

[thomas_amsler]

You can easily replace the first two hashed parts as they never change. As thebenrobb wrote they represent company and property. The third hash is like a build number and changes with every build. The last hash one only changes if you update the Analytics Extension.

[thebenrobb · Accepted solution]

We did decide to make a product change to shorten the hashes as well.  Instead of using IDs in the folder name, we've generated shorter tokens (still representing the same things of company, property, build, and extension) and using those instead.  This will not reduce the number of folders/hashes, but will greatly reduce their length.  We will also be better documenting the structure of those archive files explaining what is in them and why.

[giuseppes412756]

Thanks Rob. Would that ensure that it'll always stay under the 256 character length for any file to publish?

[thomas_amsler]

Thanks for the update, though I still hope a flat version will be provided in the future. Or an option to generate an AEM content package. Just to save us from manual tasks after each build.

[charlk79482207]

Thanks for the response, when would this be available?

[thebenrobb]

@giuseppes41275613

Impossible for us to say for two reasons:

1. We have a known folder structure, but we don't know where on your filesystem you're putting our file(s), so we can't know the overall length
2. Extension developers can provide their own JavaScript files inside of their Extensions (with arbitrary names), and those will be included as well

What I can tell you is that the longest possible paths we'll give would be:

• 13 characters for the company token and a slash
• 13 characters for the property token and a slash
• 13 characters for the build token and a slash
• 15 characters for "/hostedLibFiles"
• 33 characters for the extension ID that is providing the hostedLibFile and a slash
• the arbitrary number for the file name the extension developer provided which will obviously vary by which extensions you've installed

Altogether that's 87 + the unknown length of any library files provided by extensions.  If we say 25 is a reasonable median (no idea if this is true), then you're looking at ~112.

[thebenrobb]

@charlk79482207

Realistically, probably the 3rd or 4th week of July.  Code is written, but there's a company holiday for 5 days in July, and we're going to do significant testing with this change before release.

[jantzen_b]

Do any of the answers below answer your initial question? If so, can you select one of them as the correct answer? If none of the answers already provided answer your question, can you provide additional information to better help the community solve your question?