BFL is a library that delivers a set of commonly used Financial Algorithms. By using this library, developers can significantly reduce the development effort and remain fully compliant with the calculation engine at the same time, in other words, you can easily implement complex financial functionality in your application with little effort and take full advantage of the massive parallel in-memory processing of SAP HANA. These functions are implemented in C++ and they add a completely new and rich flavor to the development capabilities of SAP HANA.
To be able to utilize the BFL algorithms you need to install the AFL (Application Function Library) that matches the revision number of your HANA box. AFL will deliver BFL plus PAL (Predictive Analysis Library). If you would like to understand how to implement the AFL, please refer to the SAP HANA Admin Guide.
After installing the AFL you will see a new schema in your DB called _SYS_AFL. In that schema you will find all the procedures that implement the different Financial Algorithms that are part of BFL.
The list of things that you can do with BFL is huge, but in this post I’m going to focus on the Seasonal Forecasting. For the complete list of BFL functions you can refer to the SAP HANA BFL Guide.
Forecasting taking into account seasonality is a very common practice, especially in retailers where the demand is clearly driven by seasons, e.g. in an apparel store winter clothes will have greater demand in winter than in summer (duh! 
). So using traditional Forecasting methods will not produce accurate results. Coding a function to perform Seasonal Forecasting is usually very time consuming, plus, if you do it in the application layer (in a 3 tier architecture) the resulting performance will not be anywhere close to the performance that you get when you do the processing right in the DB layer where the data is stored (avoiding unnecessary data transfers from the DB to the application layer and back), in memory and taking full advantage of the massive parallel processing capabilities of SAP HANA. That is why using BFL is the path to follow.
For my example I’m going to do Weather Forecast, which is a great example for seasonality. Weather temperatures vary across the year, therefore you could say they have a seasonal behavior. As you can see in the chart below, every year is like a cycle:
The first thing is getting the data. I downloaded a flat file with daily average temperatures for the city of New York since 1980 all the way to the end of 2012 from the National Climate Data Center web site. I uploaded my data to a column table in HANA that looks like this:
Now that I have my data all set, I’m ready to start coding. In BFL there are two different functions that will allow you to do seasonal forecasting: Seasonal Simple and Seasonal Complex. Both of them will use the same code to calculate the results, the only difference is that Seasonal Simple has less input and output parameters, whereas Seasonal Complex allows you to have more control on how the data will be forecasted. To keep things simple, I’m going to use Seasonal Simple.
I’m going to forecast the daily temperatures for 2012 using all the previous years as actuals and then I’m going to compare the result of my forecast to the actual 2012 temperatures. So I’m going to build a SQL view on top of my table to filter the information and to show it the way the procedure is expecting it: the actuals table should have only column called ORIGINAL.
CREATEVIEW ORIGINAL_VIEW AS ( SELECT TEMP AS ORIGINAL FROM TEMP WHEREYEAR< 2012 ORDERBY YEARMODA );
Now I’m going to create all the input parameter tables and call the Seasonal Forecast Simple procedure. The results will be stored in a column table called FORECAST_TAB
/* This table will tell the procedure how to do the forecast.
There are multiple combinations, so please refer to the BFL
official documentation for a complete list */
DROPTABLE METHOD_TAB ;
CREATECOLUMNTABLE METHOD_TAB ( "METHOD"DOUBLE );
INSERTINTO METHOD_TAB VALUES (141113);
/* This table is used to tell the procedure how many actual
periods it should use to calculate the forecast values.
I will set it to 0 to use all the actual periods */
DROPTABLE ACTFLAG_TAB ;
CREATECOLUMNTABLE ACTFLAG_TAB ( "FLAG"DOUBLE );
INSERTINTO ACTFLAG_TAB VALUES (0);
/* This table is used to tell the procedure how many periods
account for a complete cycle. Since in this case a cycle is
a full year, then the value is 365 */
DROPTABLE PERIODNUMBER_TAB;
CREATECOLUMNTABLE PERIODNUMBER_TAB("PERIODNUMBER"DOUBLE);
INSERTINTO PERIODNUMBER_TAB VALUES (365);
/* This table will tell the procedure how many periods I want
to forecast, since I'm forecasting all 2012 and that year was
a bissextile year, then the values is 366 */
DROPTABLE FORECATPERIOD_TAB;
CREATECOLUMNTABLE FORECATPERIOD_TAB("PERIODFORECAST"DOUBLE);
INSERTINTO FORECATPERIOD_TAB VALUES (366);
/* This table will contain the results of the forecast */
DROPTABLE FORECAST_TAB;
CREATECOLUMNTABLE FORECAST_TAB ("FORECAST"DOUBLE);
/* Call the Seasonal Simple Procedure */
CALL _SYS_AFL.AFLBFL_SEASONALSIMPLE_PROC( METHOD_TAB,ACTFLAG_TAB,ORIGINAL_VIEW,PERIODNUMBER_TAB,FORECATPERIOD_TAB, FORECAST_TAB ) WITH OVERVIEW;
This is how my forecasted data looks like:
Ok, I have the result of my forecast, but I would like to know if it’s accurate or not, so I built a scripted calculation view that compares the result of the forecast with the real data:
vActual = CE_COLUMN_TABLE( TEMP );
vForecast = CE_COLUMN_TABLE( FORECAST_TAB );
vAct2012 = CE_PROJECTION( :vActual, [ "YEARMODA", "YEAR", "TEMP" ], '"YEAR" = 2012' );
var_out = CE_VERTICAL_UNION( :vAct2012, [ "YEARMODA", "TEMP" ], :vForecast, [ "FORECAST" ] );
And this is how the comparison looks like:
As you can see, the daily temperatures will hardly match because you need more information than historical records to accurately forecast them, but the seasonality was very well interpreted.
Hope you liked it!
Follow me on Twitter: @LukiSpa
Info en Español sobre SAP HANA™: