BAM_AN packages not executing by SQL jobs

I recently hit an issue with the BAM_AN packages executed through a SQL job  failing with the following message.

Object reference not set to an instance of an object.

at…. UpdateDataSourceAndGetAnnotation(String cubeName, String asServerName, String asDatabaseName, String ssServername, String ssDatabaseName)  

The reason was the account under which my SQL jobs were running did not have access to the Analysis Services. Solution was to right click on the root node –> properties and add the account under the security tab and it started working.

BAM: Regenerating data for non-RTA views

If you have log-shipped or moved your BAM databases to another environment, you might find that the legacy data in your non-rta view vanishes and only recent data is displayed.

This defeats the purpose of having scheduled aggregations to view data over months. However, there is a way to “reset” your cubes.

In the BAMPrimaryImport database, there is a table called ‘bam_Metadata_AnalysisTasks’. This table keeps track of range of records that the cube processed each time it ran. This range is also used to define the view ‘bam_<cubename>_CompletedInstancesWindow’ that is used to populated the staging tables for aggregation.

The trick is to delete all the records from this table in the BAMPrimaryImport database.

Delete from bam_Metadata_AnalysisTasks where CubeName=’<cubename>’

GO

Insert INTO bam_Metadata_AnalysisTasks(CubeName,MinRecordID,MaxRecordID,LastStartTime,LastEndTime)

VALUES (‘<cubename>’,NULL,NULL,NULL,NULL)

Note: Run the above queries for all the cubes in question. DO NOT RUN IN PROD BEFORE TESTING.

After executing the above command, run the corresponding BAM_AN_<cubename> package. After this has completed, browse to the BAM portal and you will see all historical data again.

Cheers.

BAMAlerts – The activation state cache could not be updated.

If you have log shipped or detached/attached the BAMAlerts databases, you will have issues starting the notification service on the BizTalk server for BAM alerts. The reason for this, when these databases are restored, the the ‘Cross-Database Ownership Chaining’ option on the BAMAlertsApplication and BAMAlertsNSMain databases is disabled and greyed out. Greyed out because it can only be enabled via a script.

To enable these options, run the following command (you need to be sys-admin):

–set chaining for a database

alter database BAMAlertsApplication set DB_CHAINING ON

GO

alter database BAMAlertsNSMain set DB_CHAINING ON

GO

—-

Once done, you should be able to start the BAM alerts notification service on the BizTalk Server.

Scheduling BAM Packages – failure in ‘Set global connection string variables’

I recently hit an issue while configuring a sql job to process my BAM cubes by running the BAM_AN_* packages with the following error:
Code: 0x00000000
Source: Set global connection string variables
Description: Object reference not set to an instance of an object.

I later found that this was due to the user under which the SQL Server Agent Service runs not having enough permissions on SQL Server. I changed the user to a sql server service account and I no longer got this error while running the sql job. Alternatively, you can also run this service under the network service account if your BAM databases are on a different server.

“the binary code for the script is not found…”

When you deploy a BAM activity, it creates at least one SSIS package for the activity which will create partition tables and move any activity instances within the archive window to the BAMArchive database.  If you’ve created any BAM views which create an OLAP cube, an SSIS package will also be created to move the data between the relational tables and the cube as well.  These SSIS packages are stored on the SQL server, in the MSDB database instance on the default server instance.

So SSIS needs to be installed on the SQL Server not the BizTalk server.  But what does need to be installed on the BizTalk server? See below…

You need to install:
1) Client Tools SDK
2) Client Tools Backwards Compatibility (this is critical).
+ the management tools as shown above.

I recently hit this issue while trying to run the BAM_AN_ SSIS package in SQL Server 2008 in order to load the activity data to the cube and got “the binary code for the script is not found”. What this means is the SSIS packages created by the BM utility has not been compiled. If you try and open the resulting dtsx package in Visual Studio, you are likely to see a dialog indicating that the package is corrupt. Lastly I had to  undeploy the existing BAM view and redeploy and the error went away!

Below are the screens I saw before and after installing the missing components.

Before:

After:

Hope it helps someone!