Launch API

Launchpy – Synchronizer

Hello world,

It has been a long time since I have published a blog post, but even more so for the Launch API wrapper, called launchpy. (I checked and most of the videos are from 2019, only 3 in the past 3 years). Therefore, I will recap what the launchpy module is, how it works and I will present to you what the synchronizer do.

Launchpy Recap

You can find a specific category of the blog for the launchpy python module.
It is a python module for the Launch API.

What is Launch ?

Launch is the Adobe Tag Management System, it is the direct competitor of the Google Tag Manager (GTM). It is a free product that you can have as long as you have an Adobe contract for any of the solution (Adobe Analytics, Adobe Target, Adobe Experience Platform, Customer Journey Analytics, etc….).

Launch was the first product in the Experience Cloud eco-system that was build with API-first mindset, which means that any functionality that you see on the interface is backed up with an official API.

You can find the documentation for the Launch API here.

For large organizations, capability to handle a dozen of website implementation is key for efficiency, consistency and robustness.

However Launch, and GTM, are limited on their interfaces when it comes to scale to large organization. The launchpy module is an open-source python module that helps you connect and handle large implementation efficiently. Or at least, it is its purpose.

You can find its github repo here: https://github.com/pitchmuc/launchpy

Launchpy Structure

The launchpy project already has a good documentation written in the github and has several video tutorial to get you started.

You can find the video tutorials here: Launch API video tutorial for python users

I sometime do tutorial for main release that bring new functionalities, such as the capability to upload JS file directly to Launch, via Python. Bottom of this blog post is the video for this new capability.

In a nutschell, the launchpy application is built around 3 main classes:

  • Admin Class: Allows you to retrieve company setup and properties/websites
  • Property Class: Allows you to dig into one specific property
  • Library Class: Allows you to dig into one library inside a property (managing the release cycle)

There are other classes and capabilities that gravitate around these elements (Translator and Core functionalities). I will not describe everything again, you can read about it on the official Launch documentation or on this blog pages, or via the video description.

In any case, the new capability that is being provided is coming from a mix of all of these classes and functionalities put together: The Sychronizer class.

The Synchronizer Class

Challenges of large Launch implementation

It happens that my knowledge of Launch and the different API at Adobe drags me on specific customers that have quite some complex challenges. The challenges encounter by these customers are usually mostly the same:

  1. Large amount of tags inside one property / container
  2. Difficulty to keep track on what has been done inside a property, let alone a property
  3. Difficulty to keep code consistency between the different properties
  4. Difficulty to identify and potentially roll back changes on code

While the number 1 can be worked with via architecture decisions, it is something we have a limited capability. Every tool has limitations, and having + 1000 rules / code pieces inside a property (or container) is bound to reach a limitation somewhere.
While not a road-block, it can be painful to work with very large properties.

The number 2 is definitely something that the API can help with. I have helped build some reports for customers and they make managing the properties quite effortless… if you know python.

The Synchronizer plans to help on the number 3 and 4 problems.

When face with very large organization, come very fast the problems number 1 and 2. Through a thoughtful implementation, you can imagine replicating a template implementation for all of your website, hence reducing the amount of tags per container/property.

However, now you are faced with multiple container with the same code, and when the code needs to be changed, you need to manually go to every property and change that piece of code.

Launch does not possess inheritance or synchronization protocol.

It is easy to replicate things (between properties), but keeping them in sync is much more challenging. This type of feature has been requested for almost as long as the Launch Tag Management system existed.
Unfortunately, the demand was not never backed by any sort of commitment from the Launch team.

This type of task is not easy and as Adobe tries to get a solution that works for many scenarios, it is not something trivial to achieve.

One of my client really wanted that feature and I know the steps require to achieve such task as everything was already present in my library launchpy. However, it requires knowledge of both (advanced) Python and (Launch) API to achieve it, which probably result of 10 mere people on earth able to achieve this.

So we decided to build a new class, call a Synchronizer for Launch and that will achieve what we want to have in our use-case. Taking the burden off the Launch Product Manager and basically building it myself.

Now it is time to reveal what it does and some of the implication to use it.
A more detail explanation can come later if any interest is raised and if I have time to do so.

Synchronizer Class

In summary, the Synchronizer will allow you to synchronizer or duplicate components from one property to many properties (or only one). By components, I mean the rule and the data elements.

At the moment, the duplication or synchronization of the Extension configuration are not supported. From experience, the configuration of the extensions are usually specific per property.

As it is required for any use of the launchpy library, the launchpy synchronizer class requires you to load a config file where all required information are filled to connect to the API.

Once that is done, you can directly instantiate the Synchronizer class, it is taking 2 arguments:

  • The base property : This is the property name that will be used as a template
  • The target properties: This is a list of property names where the different component will be copied.

Example of code:

import launchpy as lp

lp.importConfigFile('config.json')
synchronizor = lp.Synchronizer(base='Prop1',targets=['Prop2'])

SyncComponent method

Once this has been realized, you are now able to duplicate the component by either specifying their names or their IDs.

synchronizor.syncComponent('my Component Name')
## or
synchronizor.syncComponent(componentId='myComponentId')

Note that if you have a data element and a rule that have the same name, only the rule will be copied. If you have 2 components with the same name, the first one will be copied.

Therefore, there are few prerequisites before using it:

  • Your template property and target properties are located in the same organization
  • You have unique name for your rule and data elements
  • You have the same extension installed in both the template and target properties.
    The Synchronizer will not sync the extensions configuration.

An available option when synchronizing the rules or data element is the publishedVersion parameter. This is a boolean and is set to False by default. If set to True, takes the latest published version of the component to published it. It can be quite useful in case your rule is in Work-In-Progress state but you still want to sync your “live” version.

Note that if your rule has never been published, this option will return an error and stop the execution of the sync.

SyncComponents method

You can imagine that I provide a method where you can pass a list of component name and the list is being ran through directly.

Although this method is quite efficient when synchronizing many components, I would encourage people that have python knowledge to run the loop independently so they can better identify if an error occurs.

The method is simply running a loop based on the list provided.

createTargetsLibrary method

Once you have synchronized a lot of rule and if you already have a lot of rules, it can be very difficult to identify which rule has been sync or not recently.

Thefore, I keep all components in memory and when you call that method with a name for the library, it will create a library OR re-use an existing library with the same name to add the component to it.

You will just have to assign an environment to test the library and the synchronization.

code:

synchronizor.createTargetsLibrary('my library name')

renameComponent method

The renameComponent method allows you to rename a component on all the target properties. This is helpful if you need to rename a specific rule or data element in your base property, as the name is what is used for synchronizing the components.

It takes 2 arguments:

  • old_name : The name you want to replace.
  • new_name : The new name to be given to that component

In order to help you understand this new class better, I have done a small video below, that shows you how to use the synchronizer.

Leave a Reply

Your email address will not be published. Required fields are marked *