Overview
I have been working a little more in-depth with some aspects of BAM and the Event Bus recently and have decided to write up a few of my findings so far. This will not be a definitive entry and should expand to further blog entries in the future.
Event Bus
The BAM Event Bus that is located as a snap-in within your BizTalk Administration Console can be used to view the status of event heartbeats to the sessions currently executing. There will typically be two sessions, one for the Business Monitoring and the other for Health Monitoring.
Obviously, the extent to which these are utilised and whether they actually undertake any processing at all also depends on other external settings, such as whether global tracking has actually been enabled within the adm_Goup table. It is also worth noting that you will not have any sessions executing if the host that is responsible for your tracking is not running.
This Event Bus service is actually an assembly Microsoft.BizTalk.Bam.EventBus.dll and the method called within this assembly is TDDSDecoder.Run(). You can attach your Visual Studio debugger to the BizTalk host that is executing the Tracking service to verify this and can browse the interface in more detail if you wish by utilising the ildasm.exe utility.
The Event Bus essentially deserialises tracking data from the BizTalkMsgBoxDb and inserts into either the BizTalkDTADb and/or the BamPrimaryImport Database. The BizTalkDTADb database contains the Health monitoring data and the BamPrimaryImport database hosts the BAM data. Various stored procedures and triggers are fired to facilitate this process and you can generally leave them to their own devices.
Event Bus Settings
There are some configurable options relating to the Event Bus located within the TDDS_Settings table in the BizTalkMgmtDb database. These are pretty much self explanatory:
- RefreshInterval – Polling interval in seconds
- SqlCommandTimeout – SQL timeout period in seconds
- SessionTimeout – Time period until the sessions are torn down in seconds
- EventLoggingInterval – Interval between entries in the Event Log
- RetryCount – Number of retry attempts
- ThreadPerSession – Thread executing per session
There are some constraints on the data contained within this settings table:
- The refresh interval should be greater than 60 seconds
- The session timeout should be greater than twice the refresh interval
- The SQL command timeout should be less than the refresh interval
You will generally have no need to modify these settings. The only place I have required to do so is during development and unit testing various conditions within an application that utilises either the Health or Business Monitoring functionality that is available. It should go without saying that the default settings must be noted prior to any modifications taking place in case they adversely affect your configuration.
BAM Deployments
Deploying BAM Activities and Views is undertaken using the BM tool located within the {DRIVE}:\{BIZTALK Installation Folder}\Tracking folder. The three main parameters you utilise with this tool are highlighted below:
BM DEPLOY {BAM Definition File}[BAM Configuration File]
BM UNDEPLOY #{Change Number} [BAM Configuration File]
BM LISTCHANGES
The first option using ‘Deploy” will deploy your BAM definition either using the Excel spreadsheet you have based upon the supplied BAM template or the XML definition file. An example of usage would be:
BM DEPLOY C:\MYBAMFOLDER\MYBAMTEST.XLS
The second option undeploys a previously deployed BAM definition. You may again specify an XML definition file or an incremental identifier preceded by the hash character. Each time a un/deployment event occurs within the BAM framework it is given an incremental identifier and logged within the SQL Database.
These transaction entries can be viewed by entering the third and final most used BM operations LISTCHANGES. This will return a list of all of these entries ever since the BizTalk 2004 Server was installed. I have often found this to be a bit annoying during development when you may be un/deploying a considerable amount of times.
As this information is stored within the BAMPrimaryImport database you may do some housekeeping and clean up some obsolete entries. As before, you should use your own backup strategy prior to undertaking these steps in case you need to rollback.
All of the transactions are contained within the table bam_Metadata_Transactions. These are the corresponding entries to those returned when executing BM LISTCHANGES. The transaction ID relates to the #{Change Number}, so you can find those entries that no longer interest you and remove from this table.
However, please make a note of these Identifiers first, as there is a related table called bam_Metadata_TransationEvents that stores all events that occurred related to the individual transaction. All relating entries in this table should also be removed.
Note that you should obviously remove any deployed BAM definitions by using BM UNDEPLOY before removing any corresponding entries from the database otherwise you may have more difficulty in undeploying.