“I’ve had this post in draft for years, and it’s a format I haven’t tried before: a set of notes on how I approach designing General Ledger (GL) and Finance models. This isn’t a ‘how-to guide,’ but rather a collection of my personal considerations. I hope some of you find these insights useful.

To everyone’s surprise all users were flagged up as Administrators based on the assigned capabilities in the last couple Cognos Analytics license audits I was part of, so I’d thought I’d write this up.

Been playing lately with understanding some performance aspects of PA (obviously comparing v11 vs v12, but this post won’t be about this).

Ideally you should be always be comparing your specific TM1 model on different software versions, hardware, etc, but sometimes it’s worth having a very simple model that doesn’t contain any sensitive data, but is ’larger’ than the sample models.

I’ve been tweaking a few security models in PA recently, so it’s a good opportunity to jot down some thoughts. Here’s a list of ideas in no particular order.

Testing security

First of security is very boring and quite hard to test & verify, so it often gets overlooked. You need an ability to ‘see’ things as a user and PAW has no built-in impersonation feature (although there’s a REST API call for it, so it’s possible), so having a few dummy accounts you can login to is a must. A simple process of copying groups from a target user to a dummy user is very helpful.

I’ve been using Java extensions for calculating IRR in Planning Analytics for quite a while, but it’s time to revisit this approach with the upcoming Planning Analytics version 2.1 deprecating Java Extensions among other things.

Had another TM1 / PA archiving project recently, so a bit of a write-up of how I suggest doing these :)

Why archive PA data?

A common TM1 practice is add a ‘snapshotting’ / ‘copy’ / ‘publishing’ functionality that allows you to copy the current working data set to another version to be able to refer to it later on. Same logic as copying your working spreadsheet to ’latest_v3_final’ one :)

Recently I had a chance to work a fair bit with Cognos Analytics Rest API to automate security and thought I’d share some learnings and lessons along the way.

In the initial stage of the project when we were debating whether to use REST API or SDK for automation and I was pushing for REST API as I wanted to use Python, one of the team members mentioned that “Python has way too many libraries”, so I had to create another one by publishing the Python wrappers for Cognos Analytics calls I used :)

There are a few new TurboIntegrator functions in Planning Analytics Engine (or version 12) that do not exist (yet?) in the server version 11 that I’m working with all the time.

Thought I’d describe how we installed / upgraded Planning Analytics and Cognos Analytics on 100+ servers. TLDR: pretty much like in the picture above :)

We had a couple of iterations in this environment over the years, first for a 10.2 -> Planning Analytics upgrade and then for migration from on-prem to cloud, so we know the approach does work well. I won’t be divulging any trade secrets, it’s all bog-standard infrastructure as code with a slight PA twist. All this installation and configuration will all be magicked away with version 12 of Planning Analytics, this post will be a bit of nostalgia to come back to in a few years time.

This is post is updated on 2022/12/20 to correct a couple statements below based on the Linkedin discussion we had and add an example of commit timing.

I remember reading