Exploring the Latest Enhancements of IBM Planning Analytics Components

In this blog post, we will showcase the process of exposing the transaction logging on Planning Analytics (PA) V12 on AWS to the users. Currently, in Planning Analytics there is no user interface (UI) option to access transaction logs directly from Planning Analytics Workspace. However, there is a workaround to expose transactions to a host server and access the logs. By following these steps, you can successfully access transaction logged in Planning Analytics V12 on AWS using REST API.

Step 1: Creating an API Key in Planning Analytics Workspace

The first step in this process is to create an API key in Planning Analytics Workspace. An API key is a unique identifier that provides access to the API and allows you to authenticate your requests.

1. Navigate to the API Key Management Section: In Planning Analytics Workspace, go to the administration section where API keys are managed.
2. Generate a New API Key: Click on the option to create a new API key. Provide a name and set the necessary permissions for the key.
3. Save the API Key: Once the key is generated, save it securely. You will need this key for authenticating your requests in the following steps.

Step 2: Authenticating to Planning Analytics As a Service Using the API Key

Once you have the API key, the next step is to authenticate to Planning Analytics as a Service using this key. Authentication verifies your identity and allows you to interact with the Planning Analytics API.

1. Prepare Your Authentication Request: Use a tool like Postman or any HTTP client to create an authentication request.
2. Set the Authorization Header: Include the API key in the Authorization header of your request. The header format should be Authorization: Bearer <API Key>.
3. Send the Authentication Request: Send a request to the Planning Analytics authentication endpoint to obtain an access token.

Detailed instructions for Step 1 and Step 2 can be found in the following IBM technote:

How to Connect to Planning Analytics as a Service Database using REST API with PA API Key

Step 3: Setting Up an HTTP or TCP Server to Collect Transaction Logs

In this step, you will set up a web service that can receive and inspect HTTP or TCP requests to capture transaction logs. This is crucial if you cannot directly access the AWS server or the IBM Planning Analytics logs.

1. Choose a Web Service Framework: Select a framework like Flask or Django for Python, or any other suitable framework, to create your web service.
2. Configure the Server: Set up the server to listen for incoming HTTP or TCP requests. Ensure it can parse and store the transaction logs.
3. Test the Server Locally: Before deploying, test the server locally to ensure it is correctly configured and can handle incoming requests.

For demonstration purposes, we will use a free web service provided by Webhook.site. This service allows you to create a unique URL for receiving and inspecting HTTP requests. It is particularly useful for testing webhooks, APIs, and other HTTP request-based services.

Step 4: Subscribing to the Transaction Logs

The final step involves subscribing to the transaction logs by sending a POST request to Planning Analytics Workspace. This will direct the transaction logs to the web service you set up.

Practical Use Case for Testing IBM Planning Analytics Subscription

Below are the detailed instructions related to Step 4:

1. Copy the URL Generated from Webhook.site:
   • Visit siteand copy the generated URL (e.g., https://webhook.site/<your-unique-id>). The <your-unique-id> refers to the unique ID found in the "Get" section of the Request Details on the main page.

2. Subscribe Using Webhook.site URL:
   • Open Postman or any HTTP client.
   • Create a new POST request to the subscription endpoint of Planning Analytics.
   • In Postman, update your subscription to use the Webhook.site URL using the below post request:

• In the body of the request, paste the URL generated from Webhook.site:

{
 "URL": "https://webhook.site/your-unique-id"
}
<tm1db> is a variable that contains the name of your TM1 database.

Note: Only the transaction log entries created at or after the point of subscription will be sent to the subscriber. To stop the transaction logs, update the POST query by replacing /Subscribe with /Unsubscribe.

By following these steps, you can successfully enable and access transaction logs in Planning Analytics V12 on AWS using REST API.

print    

One of the standout features of Planning Analytics Workspace (PAW) is its ability to create calculations in the Exploration view. This feature empowers users to perform advanced calculations without the need for technical expertise. Whether you're using PAW or PAfE (Planning Analytics for Excel), the Exploration view offers a range of powerful capabilities. The Exploration view supports a variety of functions, such as aggregations, mathematical operations, conditional logic, and custom calculations. This means you have the flexibility to perform complex calculations tailored to your specific needs. 

This enables users to create complex financial calculations and business rules within the views, providing more accurate and tailored results for analysis and planning. All this can be done by the business users themselves without relying on IT or development teams, enabling faster and more agile reporting processes. This enables creating ad hoc reports and performing self-service analysis on the fly with a few simple clicks. This self-service capability puts the control in the hands of the users, eliminating the need for lengthy communication processes or waiting for IT teams to fulfill reporting requests.

In this blog post, we will focus on an exciting aspect of the Exploration view: creating MDX-based views that are dynamic and automatically update as your data changes. The beauty of these dynamic views is that users no longer need to manually select members of dimensions to keep their formulas up to date.

Similar to the functionality of dynamic subsets in dimensions, where each click in the set editor automatically generates MDX statements that can be modified, copied, and pasted, the exploration views in Planning Analytics Workspace also generate MDX statements. These MDX statements are created behind the scenes as you interact with the cube view. Just like MDX subsets, these statements can be easily customized, allowing you to fine-tune and adapt them to your specific requirements.

By being able to tweak, copy, and paste these MDX statements, you can easily build upon previous work or share your calculations with others.

Currently, the calculations are not inherently dynamic, however, there are techniques that can be employed to make the calculations adapt to changing time periods.

A classic example we can look at is performing variance analysis on P&L cube where we wish to add a variance formula to show the variance of current month from the previous month. There are many more calculations that we can consider from but we will focus on this analysis in this blog.

If we take our example, the current month and previous month keep changing every month as we roll forward and they are not static. When dealing with changing months or any member in your calculation, it's important to ensure that your calculations remain dynamic and adaptable to those changes. 

To ensure dynamic calculations that reflect changes in months, you have several options to consider:

Manual Approach: You can manually update the column dimensions with the changing months and recreate the calculations each time. However, this method is time-consuming, prone to errors, and not ideal for regular use.

Custom MDX Approach: Another option is to write custom MDX code or modify existing code to reference the months dynamically from a Control cube. While this approach offers flexibility, it can be too technical for end users.

Consolidations Approach: Create consolidations named "Current Month" and "Prior Month" and add the respective months to them as children. Then, use these consolidations in your view and calculations. This approach provides dynamic functionality, but you may need to expand the consolidations to see the specific months, which can be cumbersome.

Alias Attributes Approach: Leverage alias attributes in your MDX calculations. By assigning aliases to the members representing the current and previous months, you can dynamically reference them in your calculations. This approach combines the benefits of the previous methods, providing dynamic calculations, visibility of months, and ease of use without excessive manual adjustments.

In this blog post, we will focus on the alias attributes approach as a recommended method for achieving dynamic calculations in PAW or PAfE. We will guide you step-by-step through the process of utilizing alias attributes to ensure your calculations automatically adapt to changing months. By following this approach, you can simplify your calculations, improve efficiency, and enable non-technical users to perform dynamic variance analysis effortlessly.

To create dynamic calculations for variances between the current and prior month, you can follow these steps:

• Step 1: Ensure you have an alias attribute available in your Month dimension. If not, create a new alias attribute specifically for this purpose.
• Step 2: Update the alias with the values "Curr Month" and "Prior Month" for the respective months.
• Step 3: Open the exploration view in PAW and select the two months (current and prior) on your column or row dimension. 
• Step 4: Create your variance calculation using the exploration view's calculation capabilities. This could involve subtracting the P&L figures of the prior month from the current month, for example.
• Step 5: Open the MDX code editor and replace the actual month names in the MDX code with the corresponding alias values you updated in Step 2. You can copy the code in Notepad and use the "Find and Replace" function to make this process faster and more efficient.

By replacing the month names with the alias values, you ensure that the calculation remains dynamic and adapts to the changing months without manual intervention. When you update the alias values in the Month dimension, it will reflect in the exploration view. As a result, the months displayed in the view will be dynamically updated based on the alias values. This ensures that your calculations remain synchronized with the changing months without the need for manual adjustments.

Important Note: When selecting the months in set editor, it is crucial to explicitly select and move the individual months from the Available members' pane (left pane) to the Current set pane (right pane). This step is necessary to ensure that unnecessary actions, such as expanding a quarter to select a specific month, are not recorded in the MDX code generated in the exploration view which can potentially lead to issues while replacing the member names with alias values. 

This approach of using alias attributes to make calculations dynamic can be extended to various other calculations in Planning Analytics Workspace. It provides a flexible and user-friendly method to ensure that your calculations automatically adapt to changing dimensions or members.

That being said, it's important to note that there may be certain scenarios where alternative approaches, such as writing custom MDX code or utilizing a control cube, are necessary. Each situation is unique, and the chosen approach should align with the specific requirements and constraints of the calculation, however the proposed approach should still work for a wide variety of calculations in IBM Planning Analytics.

print