21 January 2016

OSX Nostalgia

I have to say, I really don’t like the direction the OSX interface is going. All this flatness is tremendously boring. I’ve found myself very nostalgic of the old ”Aqua” interface several times in the last few months.

Unfortunately, Jony Ive’s iron grip is so tight, all theming/customization hooks have been removed from recent OSX releases. There is now no application (that I know of) which could reskin windows, toolbars and scrollbars.

The only avenue left to UI tinkerers is icons. You can still use LiteIcon to override system icons, and of course copy-paste on individual folders. I’m currently using icons from the classic Iconfactory World of Aqua series, and I just love them.

Some programs will thankfully allow you to customize them. There are plenty of Aqua themes for Firefox, I use a slightly cheesy one. iTerm2 has an ”Aqua” option for its tabs.

If you are an app developer — please consider some skinning support. For all the talk about ”consistency” from UI nazis, the first thing people do on a new computer is still to customize the desktop background...

09 December 2015

how to fix jEdit 5.3.0 on OSX with Retina screen

jEdit is a great little editor: very flexible, much plugins, such macros, so java.
However, for some reason jEdit developers strenuously refuse to fix their OSX package to support Retina screens. Three years since these screens started getting popular, you still have to repeat the following procedure after each jEdit installation or update, in order to avoid getting blurry fonts everywhere:
  1. quit jEdit if open
  2. in Finder, right-click on jEdit in Applications, select Show Package Contents
  3. go to the Contents folder, then edit Info.plist by adding these two lines at the end of the file, just before </dict>:
    <key>NSHighResolutionCapable</key>
    <true/>
  4. force OSX to re-cache the plist by executing the following command in a terminal:
    defaults read /Applications/jEdit.app/Contents/Info.plist
  5. Restart jEdit. Icons will still look crappy (the "classic" theme slightly better than "tango"), but the rest will be ok.
On a more positive note, jEdit 5.3.0 (running on Java 1.8.0_66) seems to have fixed the crashes I've had for a year. Welcome back, "little editor that could".

09 November 2015

HFM 11.1.2.4.102 still insecure

In the last few months, I've described how HFM 11.1.2.4 is not working in secure configurations (i.e. does not support encryption/SSL):
It looks like the recently-released patch .102 still does not fix this glaring omission. Clearly security is very low in Oracle's list of priorities (but I'm sure their cloud setups are really really secure, uh-uh...).

Anyway, in the previous posts I recommended to work around this problem by having all HFM components on one single well-firewalled box. This setup was already sub-optimal (it's a single point of failure, and of course it might not meet some workload requirements), but as I went through other items it became clear that it's even more untenable than I previously thought.

This is because 11.1.2.4 components integrating with HFM (Financial Reporting, Calculation Manager, OBIEE and so on) will talk directly to application and cluster processes, bypassing the Weblogic-based web-application. Because of the previously-mentioned bug, communication will be completely unencrypted.

This means that theoretically, if any component uses the HFM API to integrate, it would have to run on the same single box as HFM.

You're going to need a bigger boat

The only exceptions to this rule are:
  • the EPM Architect Dimension Server service, which will go through the web-app for its own calls (all related to metadata, like deployment, lookups etc). However, EPM Architect's own DataSynchronization service (which can automatically copy data across EPM products) will again go directly to appserver processes without encryption.
  • webservices-based products like Financial Close Manager, Tax Governance etc (i.e. products built on Oracle SOA). These integrate with HFM via its web service interface exposed by Weblogic, which can be easily secured with SSL.

Bonus: a teaser

If you feel adventurous, you can figure out why HFM does not work with SSL.

  1. Create the EPM Registry properties mentioned in logs as reported in my first post.
  2. Run Process Monitor while you start the HFM JavaServer process.
  3. In the resulting capture, look for "File Not Found" containing "user_projects" in path. One of these files should look familiar...

07 November 2015

Link feeds about Weblogic, EPM, Hyperion etc

I've recently started using the excellent Pinboard bookmark manager (a wonderful throwback to the glory days of del.icio.us) to keep track of interesting posts. While I think about the best way to syndicate those links across all my public accounts, you can check out these feeds:

26 October 2015

Cluster strategies in Oracle Hyperion Financial Management

While poking around HFM for other reasons, I’ve found a bunch of interesting constants...
  • STR_HITREG_SERVER_STRATEGY = "ServerStrategy";
  • STR_HITREG_SERVER_STRATEGY_ROUNDROBIN = "0";
  • STR_HITREG_SERVER_STRATEGY_RANDOM = "1";
  • STR_HITREG_SERVER_STRATEGY_LOADBASED = "2”;
From other code and messages, it looks like ServerStrategy is supposed to be a property of the HFM database node in EPM Registry. It’s retrieved on startup, and will always default to 0 (”round robin”) because the property is not actually there unless you manually create it. It lseems to govern the load-distribution strategy employed by clients (i.e. the HFM web application), i.e. where to send each new login if the user has not logged on before and/or the documented StickyServer option is not enabled.

Don't raise your expectations anyway: it looks like the ”load based” strategy (2) has not actually been implemented yet, and if you choose it you’ll actually get the Round-Robin one; whereas ”Random” (1) is really random.

From what I can gather, Round-Robin will follow the list of servers specified in property serverList of the cluster node in EPM Registry, going through the list in the specified order. It’s also entirely in memory and never saved to disk or DB, from which we can deduce that:
  • each webapp or client will do its own thing, with no coordination between them;
  • each webapp or client will forget everything on restart;
  • each webapp will default to Round-Robin strategy and send logins to each appserver in the order specified by serverList
The main advice at this point is hence to keep your beefier appservers at the beginning of serverList, since they're more likely to receive traffic. Alternatively, add ServerStrategy and trust the random algorithm to distribute logins... randomly ;)

I suspect this stuff is a prelude of things to come, because it’s used in sections of code that also deal with SSL initialisation for communication with the appserver, i.e. something that is not quite baked yet but must have been added recently. It’s also pure Java, so can’t be older than 11.1.2.2. Does that mean we’ll finally get real load-balanced clustering in HFM (more than 10 years after people asked for it)…?