How To

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

Pulse-OKTA3.png

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

Executing the System Summary Report

Pulse v5.8 introduces a brand-new report, the System Summary report. This report will help TM1 administrators to monitor the health of their TM1 instances.

This report gathers all the most important Pulse data that you should look at when doing a health check of a TM1 instance such as user sessions, wait time and alerts.

Part 1 - Analysing the number of sessions vs number of alerts: This first chart will give you the number of sessions vs number of alerts:

Part 2 - Analysing wait time: On the left side you will see the Top 10 waiting time event and how long was the wait. On the right a bar chart to analyse the maximum wait time by period.

Part 3 - Analysing Alerts: This chart will give you the number of alerts by type over time.

How to run and schedule this report?

This report is only available to Pulse admin users but can be sent to anyone from a notification group. To access it, login as Admin to the Pulse Web client, from the left menu go to Reports > Performance > System Summary:

  • Select one TM1 instance

  • Select date the time frame and test the report

  • Schedule the report:

    • Select how many days of data you want to see

    • Daily Frequency of the report, how often you want it to run

    • Notification group

    • Email subject

Report time breakdown

  • If the number of days selected = 1, the breakdown will be by hours

  • If the number of days selected < 91, the breakdown will be by days

  • If the number of days selected > 90, the breakdown will be by months

 Schedule the report for the last 7 days

An example of the settings to schedule this report to be sent every day at 8:00 am containing the last 7 days of data:

Creating a new validation rule

Pulse comes with a number of built-in rules that identify common pitfalls that may slow the system or make support difficult.

Naming conventions are also validated allowing you to build consistent and easy to maintain systems.

All of these validations can be changed and added to according to your own best practices. This article will explain you how to create a new rule.

Validation rules examples

To see all existing validation rules, from the Pulse web client go to Administration and then Validation Rules, you can click on any rules to see the settings:

How to create a new validation rule

To create a new rule, just click the New button and then fill all the rules information:

  1. Rule Type: defines the type of validation rule, it can be applied against a name of an object or a rule and process.

  2. Name: Rule name.

  3. Enabled: if the rule is enabled.

  4. Description: Rule description.

  5. Remedy: Write how to fix it.

  6. Location: Enter the type of object or location for the validation rule, for multiple options separate by a comma.

  7. Regular Expression: Define the regular expression (a special text string for describing a search pattern) that will be used to search for the offending name or piece of code.

    More information on Regular Expression:

  8. Level: A number from 1 to 100, with 100 being the highest, that specifies the importance of the rule. In the validation report values of 50 or higher are errors and below 50 are warnings.

  9. Case Sensitive: Whether the rule should be case sensitive, for rule and process validation this should be false.

  10. Finally click the Save button.

Keep Pulse history when migrating Pulse

In Pulse.cfg, a new parameter ServerNameOverride has been added with Pulse v5.7.5. This new parameter enables Pulse to be moved from one server to another and all of the history be kept.
It can also be used in a scenario where the server name is regularly changed, i.e. in a virtual or cloud environment. The ServerNameOverride setting should be the name of the first server Pulse was installed on and configured for. Now when you move the files to another server or change the server name Pulse will continue using the original name.

It might be a bit confusing so let's have a look at an example. Let’s say you are currently using Pulse on one server DEV1, monitoring TM1 instances on the same machine:

1. Install Pulse into a new server DEV2

Now you want to create a new server called DEV2, and migrate the Pulse history from DEV1 to this new server. The first thing you need to do is to install Pulse on this new DEV2 server, you will now have two servers with two Pulse running:

2. Copy accross the Pulse for TM1 folder (ONLY if the Pulse version installed on both servers is the same)

In order to migrate the Pulse history from DEV1 to DEV2, you just need to copy accross the Pulse for TM1 folder:

  • Stop Pulse services on both servers DEV1 and DEV2
  • Delete Pulse for TM1 folder on DEV2 server. Before deleting the folder, backup the license file (The license file is still driven by the server name where Pulse is installed).
  • Copy the Pulse for TM1 folder from DEV1 to DEV2

If Pulse installed on DEV1 and DEV2 are two different versions, copy only the backup folders.

If the Pulse version on DEV2 is different than the one installed on DEV1, copying the all Pulse for TM1 folder will not work. In this case you will have to migrate only the folders described in this article:

3. Update ServerNameOverride parameter in Pulse.cfg

Once copied, you will have to update the Pulse.cfg in DEV2 with ServerNameOverride=DEV1. By doing so Pulse will now run on the DEV2 server using actually DEV1 as a server name. The ServerNameOverride parameter is located in the Monitoring section:

4. Check Pulse license file

The Pulse license file can be based either on your domain or on the server name. If your license file is based on your domain and if DEV1 and DEV2 server are on the same domain, you can then use the same license file on both server.
However if your license file is based on the server name where Pulse is installed. On the DEV2 server, the server name in the Pulse license file has to be DEV2. To check the server name in the license file, just open Pulse for TM1\server\License.xml and look for:

Server-Name="CW007"

Replacing the server name manually will not work. If you do not have a license file for your new server, you should request a new license by sending the new server name to your local contact at Cubewise.

5. Start Pulse services

On the DEV2 server, Pulse will now run as expected, the only difference is on the backend where it is going to use DEV1 as server name. Pulse on the DEV2 server will only monitor TM1 instances on the DEV2 server.