Everything you should know about the Pulse migration feature

The Pulse migration feature overcomes TM1's file-based architectural limitations with a centralized model that reduces risk of mistakes. This article explains everything you should know about the Pulse migration feature.

The migration concept in Pulse

Pulse provides enterprise grade migration features allowing you to easily move changes in your IBM TM1 and Planning Analytics models between servers. The migration has four important steps:

The first step is to Create a migration package, select or let Pulse select the TM1 objects you want to migrate. If you target instance is on a separate server, you will have to Download the migration package from Pulse on the source server and then import it to Pulse on the target server. The last step is to Execute the migration package. The Download and Import steps are not needed if the migration is between two TM1 instances on the same server.

The different methods to create a package

The first step when creating a migration package is to choose the method. The All package will enable you to include all TM1 objects. This method can be used to compare two instances. With the Documentation Only, Pulse will migrate the documentation input in Pulse. By choosing the Manual method, Pulse enables you to select manually the TM1 objects you want to migrate. The Source Control method allows you to query for a list of changes based on a date range and also by developer/user (leave this blank for all users) and then select the items you want to migrate.

In this example we selected the Manual method and we picked the General Ledger cube:

Review the changes

In the next screen you can review the files that are going to be included in the package, there can be 1 or 2 files depending on the type of objects selected. .cubx is a technical file in Pulse containing the cube information such as its dimensions. When migrating a dimension, the files .dimd and .dimx are included in the package.

Pulse will find all dependencies for you

After clicking Next, you will be presented with the dependencies that Pulse has found for each object in the package. Pulse recursively finds dependencies so there may be many dependencies for each object selected.

What is more here is that you don’t need to worry if you missed one object, Pulse will include all dependencies into the package. For example, if you want to migrate the General Ledger cube, just select the cube and Pulse will add the rule file, all dimensions and attributes.

One your objects have been selected, you then have 3 options:

  • Add or update the dependency on the target server.

  • Add the dependency if the objects don’t exist (default)

  • Ignore the dependency: If you choose to ignore the dependency it is possible that the package will fail to execute.

You can choose to include/exclude dependencies as required, however it is recommended that you include all dependencies. 

Live vs Offline migration

Pulse is catered for two types of migration:

  • Live Update (Hot Promote): Creates a package that can be executed on a running TM1 instance.

  • Offline Update (Cold Promote): Creates a package that contains the native TM1 files that can be copied to the target data directory once TM1 has been stopped.

The Offline package will require a restart of the target instance. You will then have to unzip it and paste these TM1 objects into the target TM1 data folder and restart the TM1 instance.

With a Live package, you will be able to migrate TM1 objects without restarting the target instance. In the package you will find technical files created by Pulse to store the information about the objects. Pulse will them use these files to create on the fly the new objects in the target instance.


Setting up Canvas logging to Pulse

Setting up Canvas logging to Pulse is quite straightforward. All the configuration happens on the Canvas side.

Step 1: Open the Canvas admin page of your application by going to the following URL:


Step 2: Enter your Canvas admin credentials

Step 3: Enter Pulse URL in the Log Visits To Pulse Address, tick Log Visits To File and finally click the Save button.

logging pulse 3.png

In the example above, Canvas will send the data to Pulse in the server cw007

Step 4: Check in Pulse Canvas Open page

Now in the Pulse > User Analytics > Canvas Open page, you will see all pages currently open by your users.

When the Logs Visits To File is ticked, Canvas will start populating the following file with the user activity, you will see the page URL, the filters and who opened the page:

You will have to repeat these steps for each Canvas application you want to track.

Configuring Pulse with CAM Security and SSO

This article describes the steps to configure Pulse to connect to a Planning Analytics instance using CAM authentication and SSO (Single Sign-on).

Step 1: Finding the CAM Passport

To connect to the TM1 instance, Pulse will require the CAM Passport from TM1 Web. There are different ways to get the CAM Passport, in this article we are going to grab the CAM Passport from one of the TM1 Web responses:

1) Open your web browser, open the developer console, go to the Network tab and make sure the Preserve log is on and the Disable cache is off.

2) Enter the TM1 Web URL, after logging in (with a TM1 user with admin rights) you should be able to see lots of responses in the Network tab.

The CAM Passport can be found in many responses. If you click on the one called tm1web.html?cam_passeport…, you will find it in the Request URL as shown below:

Step 2: Updating Pulse settings

Copy the CAM Passeport, go to the Pulse instance settings and update the following settings:

  • CAM Passeport: the one you just copied

  • Process to Keep Alive CAM Passeport: You will need to create a blank process which does nothing, Pulse will execute it every 5 min to keep the CAM Passeport alive. In this example the new TM1 process is called zPulseToKeepAliveCAMPasseport.

  • User Name: The user that you used to login to TM1 Web


Note: CAM Namespace is case sensitive, the username that you put in Pulse settings as to have the same case as the one you see in Architect:

That’s it, you can now update the documentation

Cleansing the Pulse data

Pulse v5.8 includes a new job to help removing old data in the Pulse database. By default, Pulse will keep all data from the first time it was installed in its database. To reduce the size of the Pulse database, you can now easily choose to keep only the last 360 days of history.

To do that, a new Maintenance section has been added to the conf/Pulse.cfg file including 5 new parameters:

  • MaintenanceJobHourInterval: The maintenance will execute by default each Sunday at 4:30 am (default: 0 30 4 ? * SUN *). To change this time, you will need to add a new CRON expression, you can use a CRON generator (http://www.cronmaker.com/)

  • ServerHistoricDays: The number of days of server history data to keep (Default: 0, means none active)

  • ProcessHistoryHistoricDays: The number of days of process history data to keep (Default: 0, means none active)

  • DumpFilesHistoricDays: The number of days of dump files data to keep (Default: 0, means none active)

  • PulseLogFilesHistoricDays: The number of days of Pulse logs data to keep (Default: 0, means none active)

To activate the maintenance job:

  1. Stop Pulse services

  2. Update the above Maintenance settings in the conf/Pulse.cfg

  3. Start Pulse services