Hi everyone,
We have recently migrated our property from Adobe DTM to Adobe Launch. We wanted our script to load asynchronously, hence we had removed "async" from our header script. The execution call for Direct call Rule is written in following manner in our code :
try {
window._satellite.track('commonsPageLoad');
} catch (error) {
console.error(error);
} finally {
window.digitalData = {};
}
Now , the execution starts with "try" block and call to DCR [ _satellite.track('commonsPageLoad') ] , but somehow, the "finally" block gets executed next before completing execution of DCR. This leads to clearing of datalayer , and no data goes with Adobe's image request, which is a serious concern for me.
If anyone knows the reason behind this and solution, if any, Please let me know. Many thanks in advance !
Solved! Go to Solution.
Views
Replies
Total Likes
Hi Rupali,
QQ: you said wants to load lib asynchronously, hence removed "async" this looks opposite to what Adobe suggests https://docs.adobelaunch.com/launch-reference/client-side-information/asynchronous-deployment#loadin...
If you meant wants to load it synchronously than you must add <script type="text/javascript">_satellite.pageBottom();</script> at the bottom of your tag similar to DTM. This code tells Launch that the browser parser has reached the bottom of the page since Launch likely will not have loaded and executed before this time.
This should solve your issue. btw in your second question final block is supposed to execute after the try statement completes regardless of whether an exception was thrown or caught. so to solve this issue instead of using finally block I would create a data element with the following and will call it after the image request sent to Adobe.
return window.digitalData = {};
However, I am not sure by your question, how you listening to window._satellite.track('commonsPageLoad'); and why you want to clear datalayer in each rule. (FYI! clearVar is another option for SPA)
Thanks,
Asheesh
Views
Replies
Total Likes
Hi Rupali,
QQ: you said wants to load lib asynchronously, hence removed "async" this looks opposite to what Adobe suggests https://docs.adobelaunch.com/launch-reference/client-side-information/asynchronous-deployment#loadin...
If you meant wants to load it synchronously than you must add <script type="text/javascript">_satellite.pageBottom();</script> at the bottom of your tag similar to DTM. This code tells Launch that the browser parser has reached the bottom of the page since Launch likely will not have loaded and executed before this time.
This should solve your issue. btw in your second question final block is supposed to execute after the try statement completes regardless of whether an exception was thrown or caught. so to solve this issue instead of using finally block I would create a data element with the following and will call it after the image request sent to Adobe.
return window.digitalData = {};
However, I am not sure by your question, how you listening to window._satellite.track('commonsPageLoad'); and why you want to clear datalayer in each rule. (FYI! clearVar is another option for SPA)
Thanks,
Asheesh
Views
Replies
Total Likes
Unfortunately, the code snippet in your example will always result in this manner, with the race condition if it's done outside of Launch's rule order controls (for example, if you are doing this within custom code action blocks).
In your example, " window._satellite.track('commonsPageLoad'); " gets fully executed, but it is only a direct call that then 'triggers' another, completely separate process. The separate process does not have any relationship or callback to this. The direct call gets a response that it was a valid call, but doesn't wait for further execution to complete before moving onward.
There's a few ways to provide timing control and callbacks/promises, but the easiest way to do it is to make the calls from somewhere that will still be within Launch's timing control. Adobe Launch likes to execute rules sequentially, meaning if you have pre-requisites you can create them as earlier rules on the same trigger, or direct-call them before you get to the "actions" area of the current rule. Order of operations and Launch's timing control is a fairly complex concept, because of the staging of Analytics Extension Actions, but if you add debugging outputs to the various stages, it can help tremendously.
If Rule 1 has a condition-block with the direct call to trigger Rule 2, then Launch must evaluate the conditions of Rule 2 before it can move on with the next set of conditions or actions for Rule 1, meaning executing actions of Rule 2 before performing actions of Rule 1 since the conditions of 2 were completed first (with more crazy-nuances depending on the type of action blocks you have for these rules).
If Rule 1 has an action-block with the direct call to trigger Rule 2, then Launch simply executes the direct call, and moves on to the next action immediately. This means Rule 2 ends up executing whenever it can get around to it.
Views
Replies
Total Likes
Views
Like
Replies
Views
Likes
Replies