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)…?

18 October 2015

Financial Management 11.1.2.4.101 still cannot be secured

I was hoping the recent wave of patches (.100 and .101) for HFM-- sorry, Oracle EPM Financial Management 11.1.2.4 would have started to address those well-known security problems that have been plaguing this (otherwise remarkable) release. Unfortunately, that is not the case.

To begin with, the server component is still looking for the wrong properties in registry ("isSSL" and "SSL_Port" rather than the actually existing "isSslEnabled" and "ssl_port"). This means that, whichever option you select in Configuration Utility, the component will default to ssl-disabled.

If we try to trick it, by manually adding the properties it's looking for, we get the following errors and the service shuts down:

[...] [FM] [ERROR] [] [oracle.FM.HSX.SERVER.oracle.epm.fm.hsxserver.HsxServer] [...] 
[SRC_CLASS: oracle.epm.fm.hsxserver.HsxServer] 
[SRC_METHOD: startThriftServices] An error occurred while starting HSX_SERVER_NAME service.[[
org.apache.thrift.transport.TTransportException: Either one of the KeyStore or TrustStore must be set for SSLTransportParameters
at org.apache.thrift.transport.TSSLTransportFactory.getServerSocket(TSSLTransportFactory.java:99)
at oracle.epm.fm.common.BaseSeviceManager.getSSLServerTransport(BaseSeviceManager.java:121)
at oracle.epm.fm.common.BaseSeviceManager.startService(BaseSeviceManager.java:68)
at oracle.epm.fm.hsxserver.HsxServer.startThriftServices(HsxServer.java:64)
at oracle.epm.fm.hsxserver.HsxServer.init(HsxServer.java:43)
at oracle.epm.fm.hsxserver.HsxServer.main(HsxServer.java:27)
]]
[...] An error occurred while starting HSX_SERVER_NAME service.[[
oracle.epm.fm.common.exception.HFMException: EPMHFM-66019: An error occurred while starting HSX_SERVER_NAME service.
at oracle.epm.fm.hsxserver.HsxServer.startThriftServices(HsxServer.java:70)
at oracle.epm.fm.hsxserver.HsxServer.init(HsxServer.java:43)
at oracle.epm.fm.hsxserver.HsxServer.main(HsxServer.java:27)
]]

As you can see, it complains about missing keystores. This was always a possibility, since we never got a chance to specify such a thing during configuration; however, most SSL-aware software usually ships with demo keys preconfigured for tests, so it was not unreasonable to expect HFM would do the same. No such luck!

Hopefully both problems will be comprehensively addressed sooner rather than later. As it is, secure 11.1.2.4 implementations still have to rely on both HFM web and app components running on a single box with a tight firewall, which is far from ideal.

Bonus: Peeking Under The Hood


These errors lift the veil on some of the development strategies Oracle employed to remove hard dependencies between HFM and Windows-specific DCOM.

It looks like they are using Apache Thrift, which can be roughly described as a serializer library to auto-generate network APIs for existing programs. They basically dropped DCOM network code and replaced it with a simpler network interface built on (if my speculation from the previous post is correct) some Weblogic subcomponent; this interface uses Thrift-generated serializations to pass data between appserver processes and the ADF-based web application.

In theory, such an approach could make it easier for third-party components to open connections directly to the HFM appserver, bypassing the need for specific client libraries (with their byzantine requirements) and just using Thrift to figure out necessary calls. However, I'm not really an expert in this field and I don't really know what this effort would entail; at this point, your best bet for custom integration is still likely to be the official HFM SDK.

13 October 2015

OSX 10.11 El Capitan and Kinesis Freestyle 2 Bluetooth little glitch

After upgrading to El Capitan, my Kinesis Freestyle 2 Bluetooth keyboard had a small issue, which I'm documenting here in case other people hit it.

Basically, after installing the OS update, F*/special keys were dead. Solution:
  1.  Open System Preferences -> Bluetooth
  2. Click on the X icon to the right of the keyboard, in order to un-pair it.
  3. turn the Kinesis off, then on again, and press the CONNECT button at the back of the keyboard
  4. The keyboard should pop on the screen, select it and pair it again (you will have to type a few numbers shown on screen)
All done! You should now have your special keys back.

04 October 2015

"Erase Free Space" on OSX to reclaim space

Being a heavy VMWare user, my laptop disk is always very close to being full. In a perennial search for space-saving tips, I've found a few sources mentioning the "Erase Free Space" command in Disk Utility could help reclaim a few GBs.

What is this command? Most operating systems "cheat" when deleting a file: they just mark sectors containing the file as free, without actually deleting any data. "Erase Free Space" is meant to actively write zeroes on all disk sectors reported as free, in order to actually erase content that might have been written to such sectors at some point in the past. It's a privacy / security feature, not supposed to reclaim space, but hey, it won't hurt to try! So I decided to give it a spin.

My experience was as follows:
  1. Verified that I had 34 GB of free space (out of 500).
  2. Launched Disk Utility selected the disk partition  i.e. the lowest "Macintosh HD" leaf item in tree menu.
  3. Selected the Erase tab, clicked on Erase Free Space in the lower-left area. Because I have an SSD disk, I chose the "fastest" level: excessive wear should be avoided on SSD disks as much as possible, and I was not performing this operation for security reasons anyway so I didn't really care.
  4. Observed disk free space dropping to zero in about a minute. Received message that disk is full (fair enough) and then another that Disk Utility failed to erase free space. Reported free space was now 34 GB again.
  5. At this point, retrying the operation or going to First Aid -> Verify Permissions returned all sorts of errors about the disk being locked. One error was this: "This disk needs to be repaired using the Recovery HD. Restart your computer, holding down the Command key and the R key until you see the Apple logo. When the OS X Utilities window appears, choose Disk Utility."
  6. I duly followed the procedure; however, when I launched Disk Utility in Recovery mode, almost everything was greyed out except "Verify Disk". This is because I use FileVault (i.e. total disk encryption) so the generic recovery utility, by design, has no access to the actual filesystem, which it sees as a single huge chunk of garbage data spanning the entire drive. It was a welcome surprise: it looks like this security feature actually works as it should.
  7. I clicked Verify Disk where I could (on the top disk item) and it didn't report any problem. Closed Disk Utility and went to the Apple menu -> Restart.
  8. After logon, all permissions-related commands in Disk Utility were usable again.
  9. Most importantly, I now had 39 GB of free space.
Conclusion: it was a slightly scary experience, but got me back a nifty 5GB (or 1% of drive), so I guess I'll do it again in a couple of months.  I suspect the saving might actually be due to OSX reacting to a sudden lack of free space by flushing all the semi-permanent caches it can find; either that, or it forces some sort of defragmenting/fscheck routine at the following startup that results in a more optimized filesystem. To be honest I'm not terribly curious, I'm just happy I have another trick up my sleeve!