I knocked out a brain-dump of some BAM best practices this morning for a colleague, it seems like a good thing to share more broadly. It’s a starter for 10 and I’ll refine it over time I’m sure, the book covers all of these things in far more detail as you’d expect 🙂
Avoid continuation where you can as it incurs performance overhead, it’s not the end of the world if you were to use continuation but just remember the overhead. The rule of thumb seems to be that up to 2 continuations is OK any more and you should create new activities and link them together using references.
You must always use continuation if you are writing data to an activity over time and using an eventstream other than the DirectEventStream.
If you are using continuation you must always call EndActivity passing the original ActivityID once you have enabled continuation, otherwise it can lead to orphaned activities that don’t move from Active to Completed. In short EndActivity must be called for every ActivityID used throughout the lifetime of an Activity.
es.BeginActivity(“MyActivity”, “ActivityID_1” );
…
es.UpdateActivity(“MyActivity”,”ActivityID_1”,”Name”,”Darren”);
es.EnableContinuation(“MyActivity”,”ActivityID_1”,”ActivityID_2”);
es.EndActivity(“MyActivity”,”ActivityID_1”);
….
es.UpdateActivity(“MyActivity”,”ActivityID_2”,”Age”,”99”);
es.EndActivity(“MyActivity”,”ActivityID_2”);
Run SQL queries against the SQL Views not the tables otherwise you may not retrieve all of the data due to table partioning occuring under the covers through the use of the Data Maintenance (DM) job
Schedule the DM_<ActivityName> SSIS job to ensure your Activity tables are swapped out for empty ones to maintain insertion speed
Use OrchestrationEventStream/MessagingEventStream wherever possible as this will keep the Bam data transactionally consistent with the execution of the orchestration or message in that if the orchestration rolls back the BAM data will be as well. You also benefit from being able to piggy back the orchestration persistence database roundtrip or interchange commit.
Ensure the tracking host is running if your using a EventStream other then DirectEventStream, the host responsible for tracking can be configured through the BizTalk Administration Console. This defaults to BizTalkServerApplication so ensure this host is started otherwise data will not appear in the BAMPrimaryImport database.
If your using an EventStream other than DirectEventStream then BAM data is copied out of the BizTalkMessageBox using TDDS, you can see the data pending via the Tracking Data Size perfmon counter, although if you have global tracking enabled this will also include tracking data.
BAM can store up to 1MB of data through the AddReference method on the eventstream, a great well-pefoming solution for message-bodies which enables the storage of message bodies alongside the data that describes how it was processed.