Some ETL tools out there use pure scripting to extract, load and transform data. Jedox has a classical ETL interface which allows you to re-use components and structure things in a modular, logical way.
A final note on some small(ish), cool features in Jedox 5.1. The new write back functionality allows you to directly write back to a cube via controls such as drop lists, hyperlinks and macros. If the target cell is a palo.data, Jedox will try to write the passed value into the intersection in the cube. Check out some examples here.
And web report fans will be happy (and relieved) to have available to them a custom colour palette and palette history:
The Jedox 5.1 release has been a solid step up from Jedox 5, bringing with it new innovative features to make the Jedox consultant’s life easier. I have highlighted a small selection of new functionality which enhances your existing Jedox toolset. There is a lot more here as well, such as Data Driven Modelling and R Integration which I will focus on separately in later posts. In case you missed them, here are the links to Part 1, Part 2 and Part 3 posts on 5.1.
One of the big changes for existing Jedox web users and consultants is the advent of Data Validation. This opens up a lot of possibilities for development of web entry templates and forms. The validation is essentially a format (like Excel), so therefore you can easily copy it across to other cells, or use in a Dynarange report. The list validation is similar to data validation in excel but with an important tweak: you can add additional columns to the validation array which allows you to display one value and enter another. I will run through a couple of example below:
Security is critical in any Jedox implementation. Efficient ‘lock down’ of your models are just as important to an organisation as the data they contain. There has been a need for an additional layer of security in Jedox’s database architecture for a while now.
Pre-5.1 , you could lock down cubes , dimensional elements, even cells. But you could not actually hide or restrict databases themselves. This is a hugely important step – now you can hide all assortment of databases from certain user groups. A great example that has come up time and time again for me is around Payroll models. Even though Jedox security stops unauthorised access to cubes and dimensions within a Payroll database, the fact that unauthorised users could ‘see’ the database folder name made administrators nervous. This is now a thing of the past with the Jedox developers re-writing the security model to cater for databases. There is now a separate security object (#_GROUP_DATABASE_DATA) that allows admins to restrict by group access to a database.
This new security development also opens the door potentially to a more multi-tenanted approach to model development. I have updated our security templates for database restriction and made them available :
So after a long wait, and a partner Preview since December 2013, Jedox 5.1 is finally out. Great! There has been a fair bit of noise in the last few weeks by Jedox, us (Naked Data) and a few other partners about this release. On the surface, 5.1 has some cool new features (re-skinned ETL, R Integration, Data Driven OLAP, etc), but peeking under the covers, there has certainly been a serious amount of work by the Jedox Dev team on lots of other features too.
Over my next few posts, I am going to look at them in detail – some pretty obvious and some hidden away. As usual, I will try to provide examples where relevant and a bit of context around where these can be used in real life situations.