This issue references the Monitor debugging feature of Adobe Launch found here.

Expected Behaviour

When logging a rules extension settings, we expect _satellite._monitors to evaluate data element values

This is an example of a computed data element

Actual Behaviour

When logging a rules extension settings, _satellite._monitors does not evaluate the data element value only the data element name eg %constantTest% as opposed to testValue1. (see image)

This is an example of _satellite._monitors not evaluating data elements in a rule component's settings for an Adobe Analytics Set Variables Action.

This behaviour is consistent for any settings, eg Google Ads Tack Conversion action settings below

Reproduce Scenario (including but not limited to)

1. Go to getmonita.io and open the console
2. Ensure you can see the _monitors logging events (eg rule completed, rule triggered) for different rules
3. Check the monitors logs ruleCompleted for the rule: Set Variables Adobe Analytics_monita
4. Drill down to actions[0].settings.trackerProperties.eVars[0].value
5. Results
   Expected: testValue1
   Actual: %constantTest% (as in image above)

Steps to Reproduce

1. Setup a test website with an adobe launch client side property with the following included:

• Add _satellite._monitors logging on page (use this article to setup)
• Add Adobe Analytics Extension
• Create a Data Element with name DE Test of type Constant with value: testValue1
• Create a Rule
  Rule Name: Data Element Test
  Event: Core - DOM Ready
  Action: Adobe Analytics - Set Variables.
  Add the Data Element in various parts of the set variables settings, eg in evars, props etc

2. Save Rule
3. Create and Build Library
4. Open console in Chrome and go to the test website
5. Check the monitors logs ruleCompleted for the rule: Data Element Test
6. Drill down to actions[0].settings.trackerProperties.eVars[0].value
7. Results
   Expected: testValue1
   Actual: %DE Test% (assuming we both have the same result, else let us know 😃 )

Platform and Version

Adobe Launch Client Side
Core Extension v2.0.7
Adobe Analytics Extension v1.8.5
Chrome Version 91.0.4472.77 (Official Build) (x86_64) Mac

Sample Code that illustrates the problem

See above

Logs taken while reproducing problem

N/A

Expected Behaviour

Data elements with values that are dynamic will return the same value when the user's desired action has executed.

Actual Behaviour

Data elements with values that are dynamic are evaluated when components that use them are executed, which may not correspond with the user's desired action.

Reproduce Scenario (including but not limited to)

Steps to Reproduce

For both of the following examples:

1. Create a data element of Core > Random Number type. Leave the data element configuration with its default values. Do not set any default value. Leave its Storage Duration to "None". Save it as the data element "random number"
2. Create a rule with a Core > DOM Ready event. No other events are required. No conditions are required. Actions will be added in the below examples.

Using the Adobe Analytics extension as an example:

1. In the extension configuration, set a global variable, e.g. "Page Name", and set its value to %random number%.
2. In the "DOM Ready" rule, add a "Set Variables" action. Add a variable, e.g. "eVar1", and set its value to %random number%.
3. In the same "DOM Ready" rule, add a "Send Beacon" action to send a s.t() (pageview) beacon.

Using the Facebook Pixel extension as an example:

1. In the extension configuration, set the "Pixel ID" field to %random number%.
2. In the "DOM Ready" rule, add a "Send Lead Event" action, and set its "Value" field to %random number%.

Platform and Version

All

Sample Code that illustrates the problem

See this attached Launch container: container.js.txt.
This container contains both of the above examples together.

Live demo at https://jsfiddle.net/yd0a9zLx/2/

Logs taken while reproducing problem

NA

Issue Elaboration

(Using Adobe Analytics as an example.)

A Launch user could expect that, when an Adobe Analytics beacon is sent, the variables that are sent will be evaluated at the moment when that beacon is sent. So when his variables can have different values at different moments (i.e. "dynamic"), he would expect that the "final" value is the one that is sent in the beacon.

This is the problem: If that dynamic data element had been used to set a global variable in Adobe Analytics' extension configuration, then Adobe Launch evaluates that data element's value at the moment when the configuration module's code is executed. (FWIW this is documented at the developer documentation at https://experienceleague.adobe.com/docs/launch/using/extension-dev/web/views.html?lang=en#replacing-data-element-tokens.) Then, when the "Send beacon" action is run, the global variable will be tracked with that old value, instead of whatever value the data element could have evaluated to at that action's runtime moment.

This might not be obvious to the Launch user who is unaware of the inner technical workings. As a result, what he expects -- dynamic data elements are evaluated when the beacon is sent -- is different from reality -- dynamic data elements are evaluated when the corresponding module is run.

Related story from Jennifer Kunz.

Possible Solution

Introduce a component-level setting, "Evaluate data element at runtime", that can have a true or false value.
If true (default value): the current behaviour is used, i.e. data elements are evaluated when that component's module runs.
If false: data elements are not evaluated when that component's module runs. Instead, Launch leaves it as the data element reference. I.e. instead of evaluating %data element% to the current value, it leaves its value as %data element%.

One complication of this is that extensions do not have component-level settings. So this will need to be a new feature, if this solution is accepted.

Deprecation warnings are being printed to console even with debug mode off/set to false.

Below change was made some time ago however doesn't look like its been used much until recently.

Expected behavior is that warnings are only printed to console with debug mode enabled. Otherwise they should be suppressed as per other logger functions.

On a side note there doesn't appear to be any documentation around proposed deprecated functionality...

I would like to automatically provide some data element without need for the user to create data elements for each possible items in each Launch properties.

My example is to be able to set Adobe Analytics settings as:

channel: "%digitalData.page.category.primaryCategory%"
propX: "%digitalData.page.attributes.marketID%"
propY: "%digitalData.user.0.segment.subscriptionOffer%"
prop2: "%window.location.href%"

For now, I use my extension main module:

_satellite.setVar({
	window: window,
	digitalData: window.digitalData
});

Problems

Token resolution in hydration phase

The Adobe Analytics (get-tracker) extension main module when get hydrated, synchronously read its settings (via getExtensionSettings()) that force to resolve all tokens in that settings, even before any other extensions had the opportunity to declare custom variables.

Some times it's works because the extension list is in an order where AA is after the one that call _satellite.setVar(). But it's not always the case. This order could change after a new library version is published.

There is not reliable way to provide custom vars (in extensions settings).

About the main module that couldn't be executed in reliable order:

main (optional)

[...]

This module will always be included in the runtime library and executed. Because the module is always included in the runtime library, we recommend only using a “main” module when absolutely necessary and keeping its code size minimal.

This module is not guaranteed to be executed first; other modules may be executed before it.

— Extension Manifest | Adobe Experience Platform

Non-browsable data elements

Data elements aren't browsable because it could break backward compatibility:

So you need to declare one data element per fields that exist in the datalayer, which generate a library that is quite heavy (with all generated code {modulePath:"path/to/module.js",settings:{... per datalayer fields). And it's more difficult to maintains, especially when the same configuration is used by multiple properties.

Possible solutions

The following is what I think as possible solutions.

Add a way for extensions to wait all modules to be hydrated

With an API, it could be possible to execute something only after all modules has been hydrated. Like wait a promise turbine.hydration that resolve after hydration phase?

A simplier solution without a dedicated API, is to wait the next macrotask with setTimeout(() => turbine.getExtensionSettings())?

Something that the Adobe Analytics extension (and others) could use to wait other extension to provide custom vars?

Add a ways to declare custom vars via the manifest

But I'm not sure if that solve problems. Because you will need a module to provide values? What happens if the module call turbine.getExtensionSettings(), which need to resolve tokens? It's a vicious circle (like we call it in french: "C'est le serpent qui se mord la queue")

Browsable data element

Add an option (in the manifest or in the data element's attributes) that allow data element to be "browsable" with tokens, like custom vars, event, target and this.
Why declare hundred of data elements in your property, when you need only one (like arrays myarray.0)?

Allow Launch users to define extensions hydration order

Actually I'm not sure how extensions are ordered in the library package. It looks like it's based on the revision date and/or in the library's resources list order. But I'm not sure this is a good idea, because unless you exactly what the extension do, it's will be hard to set the right values.

Centralized rules/data elements

Some way to reduce the number of data elements to maintain cross multiple properties, especially when there is lot of Tags resources. The thing is to have a library property that can be used as a "base" by an other property (kind of "extends").

See the AEPL ideas:

• Create common centralised rules/data elements shared across properties
• Add master-child management capabilities to Launch

And has been mentioned in a comment about having the ability to copy resources into other properties:

[...] totally recognize the need for a central place to modify rule components and data elements that can be used by multiple properties and managed in one place.

— @thebenrob Copy/Replicate Adobe Launch Properties (Templates)

Hey 👋

I’m looking for a way to replace turbine with something that lets me attach performance observers to each iteration of rules and tags.

Right now I can disable launch with satelliteLoaded=true, load adobe launch, then setSattelliteLoded = true. And after that - then load my custom turbine which hydrates off satellite.container. This isn’t efficient mostly because I download two engines and only run one.

Node 14 is EOL April 30, 2023 and any plugins/custom logic using ::set-output is EOL in GH Actions May 31, 2023.

upgrade to:

• actions/checkout@v3
• actions/setup-node@v3
• saucelabs/sauce-connect-action@v2

Remove:

• actions/cache@v2

use:

• Node 16

At the moment when developing private extensions we can use getSharedModule to reference reusable code from other extensions.

Would it be possible to add additional logging during runtime to notify that a specified required extension is missing?

Version 3.1.0 of webpack just got published.

This version is covered by your current version range and after updating it in your project the build failed.

webpack is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Expected Behaviour

Per the documentation https://experienceleague.adobe.com/docs/experience-platform/tags/extension-dev/web/views.html?lang=en

openCodeEditor

window.extensionBridge.openCodeEditor().then(function(code) {
  console.log(code);
});

Calling this method will show a modal allowing a user to edit a snippet of code. When the user has finished editing the code, the promise will be resolved with the updated code. If the user closes the code editor without electing to save changes, the promise will never be resolved. The options object should be structured as follows:

Per the documentation it says that if the code editor is closed without saving then the promise will not be resolved, therefore the code inside then... should not be executed

Actual Behaviour

At present if you use the following code as per documentation

function editCustomCodeConfig() {
    window.extensionBridge.openCodeEditor({
        code: window.customCodeJs.source,
        language: 'javascript'
    }).then(function(code) {
        console.log('Display code', code)
    });
}

the promise is resolved when clicking on the Cancel button of the code editor window.

The console log will log Display code undefined

This results in the code specified in the then to be executed. This results in the settings being updated even if it should not be as logic is present in the the to update the action settings.

Reproduce Scenario (including but not limited to)

This can be reproduced both in the reactor sandbox but also in production.

Create an action with a view.
Add a button to open code editor
Add code and save >> code saved successfully
Open editor again click on cancel >> you will notice that then is executed when it should not be

Version 4.17.3 of webpack was just published.

This version is covered by your current version range and after updating it in your project the build failed.

webpack is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Expected Behaviour

Passing the rule's synthetic event as parameter to turbine.getExtensionSettings() function must be possible as this function replaces token with actual values and would need the event parameter, if the extension configuration uses %event% as token (or calls a data element which in-turn uses %event%)

Actual Behaviour

Currently this function doesn't accept any parameters

Reproduce Scenario (including but not limited to)

While calling turbine.getExtensionSettings() from any custom action/condition exposed from an extension, the tokens set in the extension configuration which are dependent on %event% are always evaluated to undefined

Steps to Reproduce

1. Create an extension which-

• accepts user input in extension configuration which gets saved in extensionSettings
• has an action which calls turbine.getExtensionSettings() from inside action's code

2. Install this extension in any Launch property

3. In the extension configuration use %event...% as input. Alternatively, call a data element dependent on %event...%

4. Create a new rule with the corresponding action to be triggered

5. Check the results on webpage - The tokens are always resolved to undefined, as while calling turbine.getExtensionSettings() from inside the action's module code, currently there is no way to pass the reference of event parameter

Platform and Version

Sample Code that illustrates the problem

Logs taken while reproducing problem