Hi Ikrima. Can you offer some advice on a workflow question I have been considering. I’d like to be able to have a workflow wait for an event. So a user gets created but it waits for the objectSid to come back into the portal before sending the notification. It would seem to be simpler if all done in the one WF so I can send the random password in the email, without having to write it onto the user object. The alternative is to muck around with sets like “Created and waiting confirmation” and “Created and confirmed”. So I guess the questions are: - Is it ok to write an activity that does some kind of wait loop, or is it a dumb idea? I realise that if the FIM service went down the activity would be terminated. - Clearly the Approval activity is doing asically what want. Is there any way to tap into what it does? TIA. And

August 1, 2011

Anonymous asked: Hi Ikrima. Can you offer some advice on a workflow question I have been considering. I'd like to be able to have a workflow wait for an event. So a user gets created but it waits for the objectSid to come back into the portal before sending the notification. It would seem to be simpler if all done in the one WF so I can send the random password in the email, without having to write it onto the user object. The alternative is to muck around with sets like "Created and waiting confirmation" and "Created and confirmed". So I guess the questions are:
- Is it ok to write an activity that does some kind of wait loop, or is it a dumb idea? I realise that if the FIM service went down the activity would be terminated.
- Clearly the Approval activity is doing asically what want. Is there any way to tap into what it does?

TIA. And - are you still in Prague?

Carol

Hey Carol,

I just hit this same problem recently. The solution you’re looking for is a delay activity (it’s provided OOB by windows workflow http://msdn.microsoft.com/en-us/library/system.workflow.activities.delayactivity(v=VS.90).aspx).

What you can do is create a custom workflow activity that polls the object you’re looking for. Why not use a for-loop in code? Well that would burn CPU cycles. You should also not just call thread.sleep() since it’ll basically do the same thing and block other workflows from executing.

Using the delay activity handles all the annoying details of sending the workflow to the DB and bringing it back up for execution after the specified delay. In the mean time, other workflows can execute.

So, what you can do is>

while activity (numberOfTries < 3 || accountIsFound == true)

{

Code activity { check to see if account exists in AD. }

If-Activity (accountIsFound == false)

{

DelayActivity ( preconfiguredTimeToWaitBeforeRetry)

}

The Approval activity uses the same mechanism that the delay activity uses (the workflow guys call it passivating & hydrating) although through a different channel: instead of waiting on some specified time, the workflow waits indefinitely in the DB until a client connects to it.

Let me know if that helps!

And yup, I’m still out here in Prague enjoying Europe

Identity Management through FIM

An Ex-MSFTie's thoughts