Expand my Community achievements bar.

SOLVED

Launch self hosted: Not all files part of archive.zip?

Avatar

Level 1

Hi everybody,

i´m currently using adobe cloud hosting for FAT and Libary download for PROD environment. For some reason, if a rule is fired in PROD, the main script  tries to load a .js file that is not part of the libary. Also the path the script is trying to call has a different ID then the embedded script.

The same rule will work perfectly on FAT (when loaded from the script hosted at assets.adobe.com). I don´t see any issues with the implementation since Launch will get loaded perfectly otherwise in PROD.

i would be very thankful for any hints what might be wrong

1 Accepted Solution

Avatar

Correct answer by
Level 1

Hi Jantzen,

thanks for the support - turns out the mistake was really stupid (of me, as well as of the product imho...) - Launch generates new folders (new ID) with updates instead of keeping at structure stable (as DTM did)

So the issue really was: i overlooked that the folder-name had changed and updated the files in the previous structure. So this is why requests of course 404d.

sorry for bothering & thanks for the swift reply

View solution in original post

5 Replies

Avatar

Level 10

What js file is the rule trying to load? Does the rule have any custom code? Is there a URL where we can view the error?

Avatar

Level 1

Yes, i load small JS with custom code.

I have PMd you for details/URL

thank you!

Avatar

Level 10

I didn't recognize the domain of the request as one of Adobe's. My first suggestion would be to remove the custom script from the rule to see if you still receive the error. If it goes away, you know the reference to that resource it coming from the custom script.  At that point, you may want to check with the developer of the custom script to understand why that reference is being made.

The only reason I can think of where the rule would work fine on testing but not in production is a difference in the rule. IE has something from your testing environment not been approved and published through to production.

Avatar

Correct answer by
Level 1

Hi Jantzen,

thanks for the support - turns out the mistake was really stupid (of me, as well as of the product imho...) - Launch generates new folders (new ID) with updates instead of keeping at structure stable (as DTM did)

So the issue really was: i overlooked that the folder-name had changed and updated the files in the previous structure. So this is why requests of course 404d.

sorry for bothering & thanks for the swift reply

Avatar

Level 10

No worries! I'm glad you figured it out.