Hi,
a have a problem with BAM. We log every message the recieve time ,processtime and a lot more.
We have a batch proces that processes file. Split the file in separated messages . My problem is that of the 10000 message that are processed. 9980 are log in BAM. My question is how is the possible. I should have 10000 messages logged.
Please explain a little more here.
Where are you recording BAM checkpoints, In Orchestrations, pipelines, through custom apps, or R2 Interceptors?
Are any of the messages getting suspended before they hit the Interceptor events? Do you have on Recoverable Interchange turned on, are they being routed to Orchs/Ports where there are no interceptors?
I record in Orchestrations with biztalk2004 and i think Recoverable Interchange is introduced in biztalk2006.
Another thing is that some of my logging is completed but are still in the active table and not in the completed.
The strangs thing is, that this only happens when we proces a lot of message. We are tweaking the server so that it can process the requested amount of messages, so resources are low. Can this cause the problem?
Christian - since BAM with the Orchestration interceptor (which is what you appear to be using) uses an async path to get to the BAM primary import, you can see orchestrations finishing before BAM events are written.
Also - whatever host you have set as tracking enabled - BAM tracking data goes into the MessageBox and then back out into the tracking host and then into the BAM PrimaryImport tables. So yes - if you start to try to throttle - or if the host instances are busy doing other work you might see a delay in it moving things from the active table.
Sure a delay is fine. We use BAM for managementInfo which is processed each night.
The problem is that, it stays in the active table for ever. Are there known problems with Biztalk2004 BAM?
Can anyone help me? This is a serious problem.
This logging is used for magementinfo.
The amount of message recieved and send are different then the amount that is logged.
You should check the FailedTrackingData table in your BAM Primary Import Database. This should Tell you if you have any failures. The other thing to do is to look at your BAM_<activity Name>_Active table in the same database (BAM Primary Import) to see if you have data that stays in this table and not get processed due to issue with the scenario. Basically, you need to explain your scenario a little bit more (how orch(s)? Does your scenario use only CBR scenario?Are you using any continuations?
It seems like the activity instances stays in the Active table; In that case you have an issue that sometimes results from a race condition if you are using continuation and you are not using the EndActivity method in a certain way.
<
? 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”);
>
Please refer to the following:
http://blogs.msdn.com/darrenj/
Development walkthrough
http://msdn2.microsoft.com/en-us/library/aa995587.aspx
Here is how to remove the dangling/orphaned activity instances:
http://msdn2.microsoft.com/en-us/library/aa560758.aspx
