Workflow runtime ignores my (correctly loaded) Custom tracking ser

[Guest]

I've added 2 tracking services to the wf runtime; one is the standard
SqlTrackingService:
trackingService = new
SqlTrackingService(<trackingConnectionString>);
<workflow Runtime>.AddService(trackingService);

trackingService.IsTransactional = false;
trackingService.UseDefaultProfile = true;
This works just fine.

The other provides an "in memory" tracking service/channel which doesn't
save anything to any permanent store.

<workflow Runtime>.AddService(new
NonPersistentTrackingService(this));

This specifies it's own in memory tracking profile. It passes on any
workflow/activity tracking events, that it gets from the workflow runtime, to
a client app (by publishing events that the client subscribes to).
This works just fine when I start workflows "from the beginning" - i.e. with
this method:

<Workflow Runtime>.CreateWorkflow(<workflow Type>).Start();

The GetProfile()/TryGetProfile(), GetTrackingChannel() and Send() methods
all get called as expected.

However, if a previously passivated workflow (that had been previously
Suspended/Delayed) is loaded into a new workflow runtime, the following
happens:
1. The Workflow runtime events all work as expected (WorkflowLoaded,
WorkflowResumed, WorkflowSuspended etc ...)
2. The SqlTrackingService works as expected - when the Delay Timer
expires/workflow is Resumed, it carries on recording all the subsequent
workflow/activity events.

3. BUT The custom tracking service does nothing! It IS started (I verified
this by invoking the Start() method that it inherits from it's base
WorkflowRuntimeService class - this throws a "service already started"
exception). But the workflow runtime doesn't call it's
GetProfile()/TryGetProfile(), GetTrackingChannel() or Send() methods.

When passivated workflows are loaded into a new runtime, the "out of the
box" SqlTrackingService presumably does something to force the workflow
runtime to call it's GetProfile()/TryGetProfile(), GetTrackingChannel() and
Send() methods.
How do I get my custom tracking service to do the same??

Any help would be greatly appreciated.

 

[Wei Lu [MSFT]]

Hello learner,

I would like to get the whole project so that I can reproduce the issue.

You could send the project to my email. To reach my real email, please
remove the ONLINE in my display email.

Sincerely,

Wei Lu
Microsoft Online Community Support

==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

I have had another look at the problem and found the cause:

This problem occurs if the LoadingInterval parameter on the
SqlWorkflowPersistenceService() constructor is changed in any way after a
workflow has started.

This behaviour is easy to replicate:

1. Start a workflow in a runtime that uses SqlWorkflowPersistenceService,
SqlTrackingService and any custom tracking service. Everything will works as
expected.
2. Stop the runtime when the workflow (I’m using a sequential one) is
part way through.
3. Change the LoadingInterval parameter – making it either higher or
lower, it makes no difference.
4. Start the runtime again with the altered SqlWorkflowPersistenceService.
5. When the previously persisted workflow is loaded, it picks up
correctly from where it left of, all the workflow runtime events will work as
expected and the SqlTrackingService will do what it should. However, the
custom tracking service won't get called by the runtime. As I mentioned in my
original post, this service IS started. But the workflow runtime won't call
it's GetProfile()/TryGetProfile(), GetTrackingChannel() or Send() methods, so
it never starts tracking.
6. If, however, you perform the previous steps but omit step 3, the
custom tracking service WILL get called and it will work as expected.
7. Furthermore, any NEW instances of the workflow will be tracked
correctly by the custom tracking service.


Since changing the LoadingInterval parameter has no effect on the
SqlTrackingService – it gets called as expected, this behaviour is presumably
not “by designâ€. However, it only effects the custom tracking of workflows
that are partially completed when the LoadingInterval parameter is changed,
so it’s not a serious problem.

 

[Wei Lu [MSFT]]

Hello Graham,

Thank you for your providing. Your solution will benifit other members.

If you have any question, please feel free to let me know.


Sincerely,

Wei Lu
Microsoft Online Community Support

==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.