There are a lot of different ways to update your substitution variables. You can tweak them with EAS by hand, or use one of several different methods to automate it. Here is one method that I have been using that seems to hit a relative sweet spot in terms of flexibility, reuse-ability, and effectiveness.
First of all, why substitution variables? They come in handy because you can leave your Calc and Report scripts alone, and just change the substitution variable to the current day/week/month/year and fire off the job. You can also use them in load rules. You would do this if you only want to load in data for a particular year or period, or records that are newer than a certain date, or something similar.
The majority of my substitution variables seem to revolve around different time periods. Sometimes the level of granularity is just one period or quarter (and the year of the current period, if in a separate Years dimension), and sometimes it’s deeper (daily, hourly, and so on).
Sure, we could change the variables ourselves, manually, but where’s the fun in that? People that know me know that I have a tendency to automate anything I can, although I still try to have respect for what we have come to know as “keeping an appropriate level of human intervention” in the system. That being said, I find that automating updates to timing variables is almost always a win.
Many organizations have a fiscal calendar that is quite different than a typical (“Gregorian”) calendar with the months January through December. Not only can the fiscal calendar be quite different, it can have some weird quirks too. For example, periods may have only four weeks one year but have five weeks in other years, and on top of that, there is some arcane logic used to calculate which is which (well, it’s not really arcane, it just seems that way). The point is, though, that we don’t necessarily have the functionality on-hand that converts a calendar date into a fiscal calendar date.
One approach to this problem would be to simply create a data file (or table in a relational database, or even an Excel sheet) that maps a specific calendar date to its equivalent fiscal date counterparts. This is kind of the “brute-force” approach, but it works, and it’s simple. You just have to make sure that someone remembers to update the file from year to year.
For example, for the purposes of the date “December 22, 2008” in a cube with separate years, time, and weekday dimensions, I need to know three things: the fiscal year (probably 2008), the fiscal period (we’ll say Period 12 for the sake of simplicity, and the day of the week: day “2”). Of course, this can be very different across different companies and organizations. Monday might be the first day of the week or something. If days are included in the Time dimension, we don’t really need a separate variable here. So, the concepts are the same but the implementation will look different (as with everything in Essbase, right?).
I want something a bit “cleaner,” though. And by cleaner, I mean that I want something algorithmic to convert one date to another, not just a look-up table. Check with the Java folks in your company, if you’re lucky then they may already have a fiscal calendar class that does this for you. Or it might be Visual Basic, or C++, or something else. But, if someone else did the hard work already, then by all means, don’t reinvent the wheel.
Here is where the approaches to updating variables start to differ. You could do the whole thing in Java, updating variables with the Java API. You could have a fancy XML configuration file that is interpreted and tells the system what variables to create, where to put them, and so on. In keeping with the KISS philosophy, though, I’m going to leave the business logic separate from the variable update mechanism. Meaning this: in this case I will use just enough program code to generate the variables, then output them to a space-delimited file. I will then have a separate process that reads the file and updates the Essbase server. One of the other common approaches here would be to simply output MaxL or ESSCMD script itself, then run the file. This works great too, however, I like having “vanilla” files that I can load in to other programs if needed (or, say, use in a SQL Server DTS/SSIS job).
At the end of the day, I’ve generated a text file with conents like this:
App1 Db1 CurrentYear 2008 App1 Db1 CurrentPeriod P10 App1 Db1 CurrentWeek Week4 App2 Db1 CurrentFoo Q1
Pretty simple, right? Note that this simplified approach is only good for setting variables with a specific App/database. It needs to be modified a little to set global substitution variables (but I’m sure you are enterprising enough to figure this out — check the tech ref for the appropriate MaxL command).
At this point we could setup a MaxL script that takes variables on the command line and uses them in its commands to update the corresponding substitution variable, but there is also another way to do this: We can stuff the MaxL statement into our invocation of the MaxL shell itself. In a Windows batch file, this whole process looks like this:
SET SERVER=essbaseserver SET USER=essbaseuser SET PW=essbasepw REM generates subvar.conf file REM this is your call to the Java/VB/C/whatever program that REM updates the variable file subvarprogram.exe REM this isn't strictly needed but it makes me feel better sleep 2 REM This is batch code to read subvar.conf's 4 fields and pipe REM them into a MaxL session REM NOTE: this is ONE line of code but may show as multiple in REM your browser! FOR /f "eol=; tokens=1,2,3,4 delims=, " %%i in (subvar.conf) do echo alter database %%j.%%k set variable %%i %%l; | essmsh -s %SERVER% -l %USER% %PW% -i REM You would use the below statement for the first time you need REM to initialize the variables, but you will use the above statement REM for updates to them (you can also just create the variables in REM EAS) REM FOR /f "eol=; tokens=1,2,3,4 delims=, " %%i in (subvar.conf) do echo alter database %%j.%%k add variable %%i; | essmsh -s %SERVER% -l %USER% %PW% -i
Always remember — there’s more than one way to do it. And always be mindful of keeping things simple — but not too simple. Happy holidays, ya’ll.