Migration from Perspectives to PAX

[JohnO]

I know this is not a new topic but here I am in 2023 migrating from Perspectives to PAX (2.0.81). We don't use VBA, we don't use custom rollups or subsets within DBR's. I'm really hoping that this will not be too painful.

My interest is particularly in how well the following 2 things migrate/ work to PAX.

1) Active forms >Dynamic reports: Is there anything we should expect issues with?
2) Action buttons - I saw a post from last year that indicated the conversion tool doesn't work that well. Really? Are the issues confined to particular cases?

Also:

1) Should we expect reporting performance to be better, particularly for remote workers. If so is it where there are many DBR's used or is there a broader case for response times?
2) What's the current official acronym, PAfE or PAX - Is there an a statement somewhere from IBM?
3) Rollout of the add-in. I know it is a single file but it creates a directory structure which holds config files. Is there any standard approach to rolling out the add-in with appropriate directory structure and centralised content containing standard setting for connections, row limits, member limits etc. I saw a post here recently with scripts someone had written. Does this mean we are all on our own with this and we either have to build someone or work one on one with users to set up the add-in?
4) Does anyone have any conversion focused training material they would like to share (No harm in me asking)

Thanks

[burnstripe]

1) Active forms and slice should continue to work. Caveats when working with Pax
- Set to automatic calculation as default unless in process of building complex report
- more difficult to diagnose issues introduced when building.

2) conversion isn't great, sometimes works, sometimes not, not used enough recently to know pattern

1) PAX is a lot less chatty than perspectives, packets are bundled which yields far superior performance in pax vs perspectives over wan connections. Some companies had/have network workarounds in place to to improve perspectives performance in such scenarios so performance gain from perspectives to pax may vary but should be noticeably positive. Especially that first login.

3) see this https://www.ibm.com/docs/en/planning-an ... soft-excel

[JohnO]

Thanks for the answers

3) see this https://www.ibm.com/docs/en/planning-an ... soft-excel

I think that may only relate to the original version which had t be installed rather than the single file version which can just be opened yet still creates a folder structure with local config content?

[burnstripe]

The other option is you set up the config on one machine adding all the connections and settings you need then take a copy of the office connection folder and push that to the other users machines. The Cognos\office connection folder contains all the settings used for PAX, and can be found here
C:\Users\<UserName>\AppData\Local\Cognos\Office Connection

[gtonkin]

You are in luck John - I happened to create a script this morning to assist with some of this:

Create a .bat file with the following:

Code: Select all

@echo off

REM --Create folders if needed
IF NOT EXIST "%localappdata%\Cognos\Office Connection" (
	Echo Creating folders...
	mkdir "%localappdata%\Cognos\Office Connection"
  )


REM --Create CommManagerSettings.xml
set filename="%localappdata%\Cognos\Office Connection\CommManagerSettings.xml"

echo ^<?xml version="1.0" encoding="utf-8"?^> >%filename%
echo ^<?xml version="1.0" encoding="utf-8"?^> >>%filename%
echo ^<userSettings sections="yes"^> >>%filename%
echo   ^<setting name="Servers"^> >>%filename%
echo   ^</setting^> >>%filename%
echo   ^<setting name="EnableSSO"^> >>%filename%
echo   ^</setting^> >>%filename%
echo   ^<setting name="ClearCache"^>True^</setting^> >>%filename%
echo   ^<setting name="CheckFBAC"^>True^</setting^> >>%filename%
echo   ^<setting name="RequestTimeout"^>300^</setting^> >>%filename%
echo   ^<setting name="UseGzipCompression"^>True^</setting^> >>%filename%
echo   ^<setting name="InternalApiVersion"^>v1.1^</setting^> >>%filename%
echo   ^<Servers^> >>%filename%
echo     ^<Server gateway="https://XXX.planning-analytics.ibmcloud.com/" friendlyname="XXX PROD" dataSource="TM1OData" lastUsed="638108583085055227" wasInactive="0" state="{ &quot;DefaultProvider&quot; : &quot;odata&quot;, &quot;DefaultProxy&quot; : &quot;paw&quot;, &quot;HiddenServers&quot; : [], &quot;Version&quot; : &quot;2&quot;}" Dll="&lt;Unknown&gt;" /^> >>%filename%
echo   ^</Servers^> >>%filename%
echo ^</userSettings^> >>%filename%


REM --Create tm1features.json to use Carbon UI in PAfE
REM --Hopefully can be removed with rollout of PAW/PAfE 2.0.84
set filename="%localappdata%\Cognos\Office Connection\tm1features.json"
echo { >%filename%
echo 	"r74_EnableWebView2ForAuth": true, >>%filename%
echo 	"EnableWebView2ForCarbon": true >>%filename%
echo } >>%filename%

Use at your own risk and peril - E&O.E. etc. Test in non-production.

[JohnO]

The other option is you set up the config on one machine adding all the connections and settings you need then take a copy of the office connection folder and push that to the other users machines. The Cognos\office connection folder contains all the settings used for PAX, and can be found here
C:\Users\<UserName>\AppData\Local\Cognos\Office Connection

I had been thinking of doing this but hadn't tried feasibility.

[JohnO]

You are in luck John - I happened to create a script this morning to assist with some of this:

Thanks, that's a clever thing. But I'm wondering though if we have a centralised copy of the whole directory which includes pre-configured files wouldn't we just copy the whole directory from a central location as per the other post?

This would leave me with the challenges of :
1) Where best to place the add-in in the users laptop
2) If the user wants it as an add-in they would still need to go through manual steps
3) They would need to make manual changes to the Trust Centre?

And is there a smart way to take Perspectives away from the users laptop - I assume it might include some automated registry modification and scanning the laptop folders to find and remove instances?

This must be a problem that everyone faces, regardless of cloud deployment of the other components.

[gtonkin]

For my case, we wanted to avoid having users copying things around. I guess we could have also created a script that does the copy of the necessary files to the relevant folder. Still in testing so final deployment may change.

In terms of your questions:
1) Best place for the add-in - we rename the add-in to something generic like IBM_PAfE_x64.xll and get users to pop this on their desktop. No worries with security, admin rights etc.

2) It depends - for some users they disable the add-in in their options and just double-click or open from a pinned item. Often, users have multiple add-ins like the Oracle and SAP ones which cause issues when loaded together.

3) Trust center settings seem to vary from client to client. Some have policies in place where you cannot change anything and IT needs to intervene and roll out a policy. One of those "it depends" answers.

Best way to remove Perspectives is the uninstaller but will require administrator permissions, just like the install did.

Another consideration is that I was alerted to by Wim - https://www.infosecurity-magazine.com/n ... -ins-stop/
Not sure of the impact on the PAfE add-in just yet but one to be aware of.

[WilliamSmith]

1) PAX is a lot less chatty than perspectives, packets are bundled which yields far superior performance in pax vs perspectives over wan connections. Some companies had/have network workarounds in place to to improve perspectives performance in such scenarios so performance gain from perspectives to pax may vary but should be noticeably positive. Especially that first login.

Note: Difference between DBR and DBRW in PAX:

"DBRW works the same as the DBR function, with one major difference; DBRW reduces network traffic and may improve performance on wide area networks.

In worksheets with a large number of TM1 worksheet functions, DBRW forces TM1 to execute functions in "bundles" rather than individually. Normal DBR functions are executed individually during a worksheet recalculation. DBRW functions force TM1 to execute two passes over the worksheet. In the first pass, all changed values in cells containing DBRW functions are sent in a single bundle to the cube. In the second pass, cube values are sent in a single bundle back to the worksheet. Consequently, the worksheet recalculates twice when DBRW functions are executed."

https://www.ibm.com/docs/en/planning-an ... ic=wf-dbrw

[gtonkin]

...

Note: Difference between DBR and DBRW in PAX:

"DBRW works the same as the DBR function, with one major difference; DBRW reduces network traffic and may improve performance on wide area networks.

...
https://www.ibm.com/docs/en/planning-an ... ic=wf-dbrw

Not sure I agree with the IBM documentation - that particular line can be found in the TM1 10.2.2 reference guide, pg 185.
Things have moved on and PAfE uses REST API calls to bring zipped cellsets back i.e. optimized data.

AFAIK, DBRW and DBR are treated the same in PAfE as from a cellset point of view and REST API, cannot see how one would be optimized and the other not.

[gtonkin]

An update on this one. I got a response from Sami that DBR and DBRA are identical in PAfE (REST API world).

Documentation has also recently been updated to reflect that they are identical and both effectively WAN-optimised.

[David Usherwood]

DBRW and DBR are treated the same in PAfE

That's interesting...
I use a mix of DBR and DBRW when I need to ensure that (eg) picklists are populated (DBR) before data is retrieved/updated (DBRW). The last time I did this was with PAFe and the behaviour (which I needed) was as in the days of yore (Perspectives). Has anybody found that to have changed?

[ascheevel]

DBRW and DBR are treated the same in PAfE

That's interesting...
I use a mix of DBR and DBRW when I need to ensure that (eg) picklists are populated (DBR) before data is retrieved/updated (DBRW). The last time I did this was with PAFe and the behaviour (which I needed) was as in the days of yore (Perspectives). Has anybody found that to have changed?

I tested this last week with an example that needed a DBR in perspectives in order for a dependent DBRW to work. In PAX/PAfE, it would work either way. I was curious if using solely DBRW would force PAX to do iterative mdx calls against the TM1 server, but found MDX chatter to be identical in both cases i.e. the query on the reference cell (needs DBR in perspectives) would execute first regardless if it was DBR or DBRW and the resulting value would always be in the secondary DBRW's mdx call back to the server.