A Simple Architect Replacement for Linux

Post Reply
bgregs
Posts: 62
Joined: Wed Sep 12, 2018 11:19 am
OLAP Product: TM1 / Planning Analytics
Version: 2.0
Excel Version: 2016

A Simple Architect Replacement for Linux

Post by bgregs » Tue Jul 28, 2020 8:27 pm

A while back I started playing around with GUI design using the GTK library (completely unrelated), and used TM1's Architect as a simple model. Fast forward a few months of on/off (mostly off) development, and I ended up with a project that actually had a bit of potential.

What I now have is a GUI frame that uses embedded Python to pull in REST API objects from a TM1 instance. In its current form the project is very bare bones, but functionality is easily added with just relatively minor updates. As time and interest permits, I will continue to update the project with new features (batch TI commits, cube viewer through the Web API JS library, etc.).

For now, the project is only compatible with *nix based systems (mostly due to how I handle file access), but this could change if the interest in a Windows port is high enough. I mostly plan on using this project as a testing ground for various techniques, but I do believe that it has potential given enough TLC. One of the main goals is to keep the project simple and open, so it can be easily ported to fit different needs for different people.

As it currently stands, I can successfully browse Cube and Process names on a Linux box, but not much more. Process edits through user defined text editors (default is VIM) will begin development shortly. In the meantime, feel free play with, modify, or ignore the project until it gets a bit more meat on its bones.

The project can be viewed and copied at: https://github.com/bgregs514/OpenCubes

Screenshots are attached for those interested.
Attachments
settings.png
settings.png (65.88 KiB) Viewed 159 times
main.png
main.png (81.94 KiB) Viewed 164 times
error.png
error.png (7.03 KiB) Viewed 164 times

asutcliffe
Regular Participant
Posts: 164
Joined: Tue May 04, 2010 10:49 am
OLAP Product: Cognos TM1
Version: 9.4.1 - 10.1
Excel Version: 2003 and 2007

Re: A Simple Architect Replacement for Linux

Post by asutcliffe » Sat Aug 01, 2020 8:53 pm

OpenCubes is a cool name, I'm going to have a look ;)

asutcliffe
Regular Participant
Posts: 164
Joined: Tue May 04, 2010 10:49 am
OLAP Product: Cognos TM1
Version: 9.4.1 - 10.1
Excel Version: 2003 and 2007

Re: A Simple Architect Replacement for Linux

Post by asutcliffe » Sat Aug 01, 2020 10:32 pm

So I cloned it, and it compiled once I'd installed the relevant gtk headers.

I was able to authenticate and get a list of cubes for a server, not processes though. Be careful with storing the credentials like that and make sure you at least keep them out version control with a sensible .gitignore. It looks like a fun project, go for it :)

bgregs
Posts: 62
Joined: Wed Sep 12, 2018 11:19 am
OLAP Product: TM1 / Planning Analytics
Version: 2.0
Excel Version: 2016

Re: A Simple Architect Replacement for Linux

Post by bgregs » Mon Aug 03, 2020 1:23 pm

@asutcliffe

Thank you for checking out the project! You hit on a couple points that I thought would be good to address in order to clarify the state of application.

Compiling and Installing: The Makefile is admittedly very lightweight. I do plan on adding some dependency checking and better handling in the future so it won't be a mystery as to which headers are missing. Sorry about that, but thanks for mentioning it!

Features: Currently a cube listing is all that is returned, but there is actually a section of commented code buried in there where I've begun work on processes. Now that the general gtk frame is in place, the actual implementation of returned data from the TM1 instance is pretty quick. I'm away from my dev space for the next couple days, but should be able to have some significant updates to core functionality rolling out in the next couple of weeks. Stay tuned!

Security: This was actually an intentional decision on my part. I actually placed a comment in the .conf file that is generated during the first run:

Code: Select all

#define PASS_COMMENT "Use the shell to pull this in from a secure file if you prefer"
Given that this is built (as of now) as a Linux/Unix tool, I intended to handle the security parameters in the .conf file as most other simple applications. The general way of securing your parameters in a config file on Linux is through the GPG utility. You can implement it through something like this: https://wiki.archlinux.org/index.php/Mu ... management.

Given that there are ways to secure parameters outside of me having to handle it (and most applications for *nix will implement something similar), I always prefer to leave this in the hands of the users. Unless there's a significant reason to why the application should handle it, I prefer to follow the "do one thing and do it well" methodology of *nix based design.

Thanks again for checking out the project! Any and all feedback is welcome, so please feel free to throw out ideas as they come up!

Post Reply