How to Resume the Persisted Workflow with Delay Activity without Reloading into memory:
I am creating a workflow for leave application. My requirement is if any participant is not responded in the specified time, then the request needs to pass to next level participant approval.
Suppose a requester submitted a Leave Request and the Team Lead needs to approve it within 7 days. If the Team Lead is not responded in 7 days, then automatically it has to go to Manager Approval.
In general to achieve this, we will write a Windows service which is checking periodically and send the notifications once the period is elapsed.
But I want to achieve without writing the Windows service. Is there any possibility in WF4.0.
I am trying like this, once the requester is submitted the request then I am showing the request in the participant mail box and persisting the workflow. Once the participant responded I am resuming the workflow (because I am saving the workflow instance ID) and passing the participant response for further workflow execution.
In this if the participant is not responded, how to escalate / send the request to manager without using windows service.
Is it possible to do with anything with the Delay Activity?
If you create a workflow service it is hosted in the WoskflowServiceHost and this periodically checks is there are expired timers and resumes those.
You must host the workflow engine somewhere ...
If it's not in a windows service, it should be in IIS.
You can also host it in a "normal" command line application, but if you close the application the workflow will stop.
Related
After saving a data, I wait for the confirmation of the opposite server. With a different endpoint, I want to constantly check this server's approval check in the background. I want to send requests continuously until the transaction is approved and when it is approved, I want to take action. How can I make a request to a persistent endpoint?
From which sources should I get help, if there are examples, I would like to examine them.
Let's say we need to send user an email and wait for user to reply and then continue the workflow. Should we create an async activity to send the email, and when the reply email comes, we complete the activity? Or should we create a normal activity to send the email, and then the workflow await a signal, and when the reply email comes, we send the signal to the workflow? Are these 2 options equivalent? Or there are some difference can be used to decide which one to use for different activities?
Thanks in advance
I recommend the activity then signal approach for this use case. The reason is that sending an email and waiting for a reply are two different tasks with different timeouts and retry policies.
If send email activity fails it is expected to be retried on a short timeout on a pretty tight retry schedule. At the same time the timeout for the user action is expected to be much larger (potentially days or weeks) and is usually not retriable.
Edit to answer the retry question:
But what if we do want to retry? Say we expect the user to reply the
email within a day, otherwise we send it again. We can retry the
entire workflow but that is not ideal since send email and user reply
is only part of the workflow. Should we make it a child workflow and
have retry on the child workflow?
You retry the whole interaction. See the fileprocessing example of retrying part of a workflow. Here are Go SDK and Java SDK versions of it.
In our design we have something of a paradox. We have a database of projects. Each project has a status. We have a REST api to change a project from “Ready” status to “Cleanup” status. Two things must happen.
update the status in the database
send out an email to the approvers
Currently RESTful api does 1, and if that is successful, do 2.
But sometimes the email fails to send. But since (1) is already committed, it is not possible to rollback.
I don't want to send the email prior to commit, because I want to make sure the commit is successful before sending the email.
I thought about undoing step 1, but that is very hard. The status change involves adding new records to the history table, so I need to delete them. And if another person make other changes concurrently, the undo might get messed up.
So what can I do? If (2) fails, should I return “200 OK” to the client?
Seems like the best option is to return “500 Server Error” with error message that says “The project status was changed. However, sending the email to the approvers failed. Please take appropriate action.”
Perhaps I should not try to do 1 + 2 in a single operation? But that just puts the burden on the client, which is worse!
Just some random thoughts:
You can have a notification sent status flag along with a datetime of submission. When an email is successful then it flips, if not then it stays. When changes are submitted then your code iterates through ALL unsent notifications and tries to send. No idea what backend db you are suing but I believe many have the functionality to send emails as well. You could have a scheduled Job (SQL Server Agent for MSSQL) that runs hourly and tries to send if the datetime of the submission is lapsed a certain amount or starts setting off alarms if it fails as well.
If ti is that insanely important then maybe you could integrate a third party service such as sendgrid to run as a backup sending mech. That of course would be more $$ though...
Traditionally I've always separated functions like this into a backend worker process that handles this kind of administrative tasking stuff across many different applications. Some notifications get sent out every morning. Some get sent out every 15 minutes. Some are weekly summaries. If I run into a crash and burn then I light up the event log and we are (lucky/unlucky) enough to have server monitoring tools that alert us on specified application events.
In my app, I get Lync Presence of our employees through UCWA. It works fine, but I need to knock to Lync with reportMyActivity every 3-4 minute.
I don't need to get presence info at night when employees are not at work, so I stop reportingMyActivity at the end of the working day and resume at it's beginning. Then trying to extend presence subscription, and if I get 404, I create new presence subscription. But no presence updates after those manipulations.
Is it designed to work this way? How could I avoid reportingMyActivity at night?
If you don't do reportMyActivity your Application will be drained, because assumed inactive.
I think you only have two options then:
Keep doing reportMyActivity regurarly also at night, you'll just stop extending presence subscription. Very likely you'll have to manage access token expiration too, which is normally 8 hours valid
You let the App shut down, and a complete new token acquisition, Application creation, presence subscription flow will start next morning
Let me explain the scenario. I want to start a workflow instance which will create a request approval process. There are different levels and each level has approvers and specific time is assigned for each level. An approver should approve within the given time to complete process or he/she may be alert again to approve once the assigned time of the level is over.
A user may request something by starting a approval process this would intiate a workflow which will create a workflow instance for the specific request. when the process starts it will inform the respective approvers in first level to approve the request made by a user. if a approver failed to approve within the given level time the approver will be alerted to approve the request and it should pause the workflow and wait for it. if he managed to approve the request the process should moved to the next level and continue with the same process until the number of levels are over.
Can i do this using windows workflow foundation. I read and understood that invoking a workflow, bookmarks can be used for this. i need to how can i manged the background timer for each level and alert the users. im stucked at that point please help me.
if there is a better solution please feel free to talk :).
Yes you can achieve this by using a Pick activity which has a timer (delay) activity and your custom approval activity inside. Pick activity will choose only one PickBranch to complete when ever either of the contained activity is completed. That said if the timer activity is triggered, the custom approval activity will be cancelled then. And you can choose to do what ever you what to do afterward such as sending emails to notify the involved approvers that the task was expired. WF has a lot of potential but it seems this technology has been left in the corner by its vendor for a while...