Comments on: MsmqActivities v1.1 Released

By: Tomas Restrepo

Tomas Restrepo — Tue, 12 May 2009 17:25:29 +0000

Larry: If you look at the code, the workflow instance id is obtained in the runtime service (MsmqListenerService), in the Subscribe() method simply by using WorkflowEnvironment.WorkflowInstanceId.

The Subscribe() method is called by the MsmqReceiveActivity from its implementation of IEventActivity.Subscribe()

By: Larry

Larry — Tue, 12 May 2009 16:06:55 +0000

Yes, I am referring to the workflow instance ID.

By: Tomas Restrepo

Tomas Restrepo — Mon, 11 May 2009 17:35:06 +0000

Larry: Not sure I understand the question. Are you referring to the Workflow Instance ID stored in the subscription db?

By: Larry

Larry — Mon, 11 May 2009 15:23:20 +0000

Hi Tomas,

It appears this handles the situation where we would need to have the context information like is supplied with the wsHttpContext and other context related bindings. Although I can write a custom binding for the ReceiveActivity to connect to MSMQ, MSMQ does not have the context information.

How are you getting the instance ID?

By: Tomas Restrepo

Tomas Restrepo — Thu, 15 Mar 2007 16:25:03 +0000

Dub,
Absolutely right. I’ve fixed it and updated the download. Thanks!

By: Dub

Dub — Thu, 15 Mar 2007 04:36:04 +0000

bug (SqlMsmqSubscriptionPersistenceService.cs):
public SqlMsmqSubscriptionPersistenceService(string connString)
{
if ( String.IsNullOrEmpty(_connectionString) )
throw new ArgumentNullException("connString");
_connectionString = connString;
}

By: Jon Flanders

Jon Flanders — Fri, 20 Oct 2006 22:00:20 +0000

I think you are correct that handling WorkflowLoaded won’t work in this case -sorry I wasn’t thinking it throught.
I am still concerned about your approach (essentially another persistence service to take care of). Especially in light of:
a) How will this work in a mulit-host instance environment
b) How will it stay consistent with the state of the workflow itself (what if your service gets out of sync with the current state of the workflow).
Which is why I would prefer some system that used the metadata of the activity instance itself – I would lean toward SqlPersistenceService.GetAllWorkflows – which would allow you to get the activity metadata without having to load it into memory. OTOH – this is only on the OOB persistence service.

By: Tomas Restrepo

Tomas Restrepo — Fri, 20 Oct 2006 20:44:03 +0000

Jon,
I thought about doing something similar, but I was under the impression that wouldn’t quite work. Here’s what I was thinking:
If the workflow is "stuck" waiting for the MSMQ message to arrive at the queue, and the host is unloaded, then when the host was reloaded the workflow instance wouldn’t have been reloaded by the engine because it was idled and not running (at least that’s what I understood from our earlier discussion in the forums). If so, hooking into the WorkflowLoaded event wouldn’t do me any good as it is precisely my MsmqListenerService the one would be responsible for "waking" the workflow.
Besides of this, I don’t see how hooking into the WorkflowLoaded event would’ve saved me the trouble of keeping track of the active subscriptions in a persistent store. Maybe I’m missing something, in which case I’d sure appreciate a hint

By: Jon Flanders

Jon Flanders — Fri, 20 Oct 2006 20:33:22 +0000

Hey Tomas – sorry I missed your earlier entry – but why not just have your service hook into the WorkflowLoaded event? That way if a Workflow came up from the persistence store and you didn’t have a listener – you could recreate it from the Workflow definition (e.WorkflowInstance.GetWorkflowDefinition()).