BAM captures milestones for objects derived from Microsoft.BizTalk.Bam.EventObservation.EventStream in Coordinated Universal Time (UTC) format. When you send dates/times to BAM using the APIs, they are received in the format sent with no conversion to UTC format.
📝 One-Minute Brief
If your BAM Portal shows incorrect timestamps (e.g., being off by several hours), it is likely due to how BizTalk stores data. BizTalk Server stores all tracking information in the BAM databases in Coordinated Universal Time (UTC). While the BAM Portal attempts to convert this to your local browser time, discrepancies often arise due to server-side time zone settings or how the BAM views are defined. The solution involves verifying the time zone of the SQL Server hosting the BAM databases and understanding that the “raw” data will always be in UTC.
One of the most common complaints from business users using the BizTalk BAM Portal is: “The message arrived at 10:00 AM, but the portal says it was 2:00 PM. Why is the time wrong?”
The short answer is: It isn’t wrong; it’s just in UTC.
If you use local time, the times will not be converted to UTC format and will be out of sequence relative to UTC times that are recorded.
To solve this problem, modify your data to make it conform to UTC format.
Cause
BizTalk Server is designed for global enterprises. To ensure that events happening in London, New York, and Tokyo can be sequenced correctly, BizTalk stores all tracking data in the BAM databases using Coordinated Universal Time (UTC).
BAM API Sample
Here is a sample of the BAM API to ensure the timestamp is in UTC.
Global.es.BeginActivity("BAMApiPo",poid.ToString());
Global.es.UpdateActivity("BAMApiPo",poid.ToString(),
"Received",DateTime.UtcNow,
"Product",xePO.SelectSingleNode("Product").InnerText,
"Amount",xePO.SelectSingleNode("Price").InnerText);
Global.es.UpdateActivity("BAMApiPo",poid.ToString(),
"Packaged",DateTime.UtcNow);
Global.es.EndActivity("BAMApiPo",poid.ToString());
