MicroStrategy Administrator iPhone App: Part 1
Since I first started in MicroStrategy, I really wanted the ability to administer the system from my mobile phone. I’ve built applications to intelligently start/stop subscriptions based on system resources, ETL status, data integrity and monitor system availability, but no matter what I could do, it would inevitably lead to me having to email myself to take action. And if I’m away from my desk (or asleep in my bed), that meant having to go find my laptop, connect to a VPN, Remote Desktop, and then more than likely just push one button. I dreamed of the day I could receive an alert and just handle it right there from my phone.
My first smart phone was a Blackberry, and after some experimentation I found that I just wasn’t cut out for Blackberry development (at least in 2007). Enter the iPhone and development became a much more real option. It’s still very much a work in progress, but today I present to you my first take at a MicroStrategy Administrator app for the iPhone (and Android)!
This was an incredibly long project for me and I learned a lot about a lot of things. I’d like to share it all, but it’s too big for one blog post (I’ve been writing this one off and on for weeks). What i’ll do is break it up into piece to make it more manageable and interesting. This post will be lengthy as I discuss at a high level what went on and where it’s at. Separate, future posts will discuss the technical details (with source code!) of the various pieces of the application. Enjoy.
The biggest problem was how I was going to get the information to administer the system. The IServer COM SDK looked like the place I needed to go, but of course that doesn’t help me in a mobile environment. My plan was to write a server side application that my phone could connect to and send/receive data/commands. I’ve had some success writing apps with the COM SDK in the past, but I definitely wasn’t looking forward to it. Just then, I stumbled on a TechNote that highlighted some new additions to the Java SDK in 9.0 that had every gem I could wish for: Job Monitor, Killing Jobs, Connection Monitor and Purging Caches! That’s quite a good start for an Administration app. In just a few quick hours, I put together a simple Java server app that could accept incoming connections and respond to simple command requests supporting all of those features, as well as Schedule listing and Schedule pausing.
While this was good as an initial proof of concept, the fact is that since it was a client/server application, it meant my phone application had to manage the session, check for disconnects, etc. This was too much complication to handle on the phone, so I had the idea of converting this app into a Java Web Service. After a long, grueling fight (open source can really be a pain sometimes), I finally got everything up and running. This design works much better, as the JWS handles connectivity itself and the phone just makes “dumb calls” to the web service to ask for things. The JWS can connect when it needs as well as pool the connection between lots of simultaneous admin users.
Update: Check out the full code and walkthrough in Part 2.
Native iOS applications are written in Objective-C, so I first started this project by picking up a book and getting to work. I’m a hobbyist programmer and a Computer Science major, but Obj-C was a bit too low level of a language for me. I struggled through it for a few weeks off and on and did manage to get a functioning prototype up and running on my phone, but it was a huge chore to add even the most basic functionality. Nearly every line of code required dozens of Google searches to devine.
After shelving the project for a few months, thankfully Flex 4.5 was released. I was already finding a lot of success in Flex development from building visualizations, and immediately found success with 4.5 by porting those straight to iOS. After tinkering with 4.5 and Spark for awhile and catching some free online Flex training sessions, I dusted off my old Java Administration Backend application and got to work rebuilding the Mobile piece using Flex. In about 90 minutes, I reached feature parity with my previous Obj-C attempt that I spent well over 20hrs on.
Flash Builder 4.5 is really nice to develop with, and Adobe has done a great job in allowing you to rapidly develop. I had nearly a fully functional application up and running without having to actually write any code! Everything was handled by simply dragging the controls onto the screen and choosing their targets. Even after connecting my Web Service, I just had to drag each function (getJobs, getUsers, getSchedules) into the List control of that View, and it magically linked everything up for me. Adding new Admin functions to this app is as easy as a new function in the Web Service and a drag/drop in Flash Builder.
Going with the Web Services back end was definitely the right call. The phone app simply requests whatever piece of data it wants and doesn’t have to do anything but wait for a response. This makes it seamless to handle things like background processing on the iPhone. Whereas before, I’d have to worry about what happened to my TCP/IP connection, now the next Web Service call, even if it comes days later, gets answered just the same as if it was submitted immediately after the last. If the MicroStrategy session timed out between the two calls, my Java Web Service can easily reconnect, as opposed to having to handle that kind of logic from the phone which would cause extra traffic.
This is going to be the hardest thing to overcome. My initial idea was that I would send the Device ID with every call. You’d have to authorize a Device for use from the server side (via some configuration file) and if the request wasn’t authenticated with an approved Device ID, then it would be denied. This would prevent someone from stumbling on your web service and simply invoking the administration methods directly. I immediately hit a snag when I found that Adobe hasn’t included access to the Device ID yet, but a serviceable work around was to use the device’s MAC Address instead. While not ideal, it’s the best alternative I could find. I’ll probably end up hashing it into some non-identifiable key, and using it that way for security.
Security wise though, the biggest concern is having a Web Service with administrative powers and connectivity to your IServer exposed on the internet, not to mention in it’s current form, you’d have to run it using Tomcat which most Windows users aren’t going to be familiar enough with to secure. While the simple solution is to keep the Web Service on an internal network and simply VPN from your phone (that’s what I’m currently doing) this raises to issues. The first is that you may not be able to VPN from your phone due to your company’s security policies, and two is really takes a lot of the convenience out by needing to connect via VPN before you can use it. Sometimes I just want to take a quick peak and see how things are running, and it’s a chore to spend a minute connecting/running/disconnecting.
To compound the Web Services problem, I also haven’t found a way to handle any kind of NT/LDAP Authentication, so right now it only supports Anonymous, which isn’t ideal.
Here’s a short video showing off a few features. It’s built using Adobe Flash Builder 4.5, so this is running in debug mode on my Desktop. It is then deployed as shown to iPhone and Android.
Currently, I’ve implemented the following features:
- Job Monitor
- View Jobs running with User, Report, Elapsed Run Time
- View SQL
- Kill Job
- User Connections
- View Users and Projects
- Disconnect Users
- View Schedules
- Disable Schedules (this is done by setting the Start Time to a date in the future)
- Provide the URL to the JWS. This value is saved to the device locally.
I’ve got partial code or plans to implement the following:
- Cache Monitor
- View Caches by Project
- Clear Report Caches and Prompt Caches by Project
- Refresh Intelligent Cubes
- User Management
- Disable User Accounts
- Trigger Schedules
- Web Server