Libraries and accessibility

[sriram_devadas]

Is is possible for extensions in a library to access data layer items in other libraries? If yes, is it okay to do this as a matter of best practices or something to be avoided?

[bahman_sarram · Accepted solution]

Hi Sriram; A standalone library cannot access data layer items from another library in Tealium IQ interface. Only a profile can access data layer items from libraries it imports. So if Library A and Library B have their own data sources and are imported into Profile "Main": Profile Main can have its own extensions access data layer items from Library A and Library B But Library A extensions cannot access Library B data layer items and vice versa. (specifically talking about in the IQ interface) hope this helps!

[son_hoang]

Just to throw in my own comments. The concept of the library is that it is a self-contained. If you need two separate libraries to interact in some way, they should probably be combined into one so that their interactions are consistent and easily understood.

[jared_hislop]

Sriram, If a library is setting a global variable in an extension, that variable is accessible in other libraries (depending on load order) or profiles. This global variable would be set in the utag_data object or as a basic global javascript variable. However, if you're talking about variables in the dropdowns of extensions then, as Bahman points out, these are not accessible from library to library, only in the profile that imports the library.

[sriram_devadas]

Thanks Bahman and Son. We were just considering alternate library designs with respect to deployment. One option which came up was to divide the libraries logically based on our UDO, and perhaps have separate libraries for tags. Then use this to do 'out-of-band' releases not tied to our site release cycle for new pixels etc. The question was if a library needs to reach out to another for a common data layer object, how we would do this. Your answers make sense in this scenario, libraries should not have to reach other to access each other's data layer items. We should be able to manage our requirements with self-contained libraries and multiple profiles.

[raghbir_singh]

To take Sriram's problem further, how does Tealium fit in a common release cycle? Say a Developer D is working on a feature F that needs a change in Tealium. QE Q is testing feature G of the site which may not need feature F changes. And production file should not have either of features F and G. How does Tealium recommend doing this and probably doing a patch to test and production environments while development is making changes for the next release ?

[tomomi_chu]

I noticed assigning extensions from a library cannot be assigned to tags within the profile it's shared. That sucks. I was hoping to just build an extension once and then share it to a tag that is specified to a profile. Will there be any changes to these limitations? I'd prefer to use the library as way to minimize duplication of work across numerous properties. Also it'd be great to have the ability to delete unused libraries. PLEASE!

[ralderson]

Picking this up from Tomimi. This is exactly what I was trying to do until I ran into the same problem. I don't want to duplicate extension code across our 30+ profiles (and maintain each and every version of that code). The only solution I can think of is to have the extension code in an external S3 bucket and to have Tealium pull in the shared code via jQuery.getScript().  Not exactly an optimal solution and not without it's share of CORS issues.

Is there anything on the Tealium roadmap to address this limitation?

[craig_rouse]

Hi @ralderson

I'd be interested to understand why you need to scope the extension to a specific tag. What's preventing you from using "All Tags" scope in this case? You could also use "DOM Ready" if you want to make sure the code only runs once.

I agree that having the ability to scope extensions to specific tags within the profile that inherited it would be a useful addition, but unfortunately it's just not possible right now. I have internally logged a feature request to see if we can get this added, but this probably won't be available for some time.

If you can share some more details about your use case for this, we may be able to help you find a suitable workaround.

Thanks,

Craig.

[ralderson]

Hi Craig,

With enterprise solutions there are often multiple tags running (even multiple GA tags) to ensure that different teams/departments get the correct data delivered to their specific profiles and accounts (some accounts seperately tracking a specific subset of the data of other accounts). We don't necessarily want the same data written to the same custom dimensions for all profiles, which is something that these shared methods would end up doing for "All Tags".

I believe there must be multiple recognized use-cases since Tealium has specifically built this capability in to the platform rather than just offering "All Tags", "DOM Ready" and "Pre-Loader"

The timing of DOM Ready also isn't ideal. We often dispatch events between the time that Tealium has loaded everything and the DOM being ready, and so any event listeners loaded DOM Ready would not be available in time to catch the events.

I'll play around a bit and either post any solution I come up with or come back to you with a more specific example for brainstorming, if that is ok with you?

Rob

[craig_rouse]

That's perfect - thanks, Rob.