I've got a DynamoDB in AWS and it has a trigger on it with an AWS Lambda connected.
I need to send an email when a status reaches a particular value and it's done checking the EventName=="MODIFY" and the newImage["Status"] value.
What currently happens is that the event is fired 3 times and so 3 emails are sent...
I thought to set a value on DynamoDB telling that I've already sent an email, but doing so another trigger is fired and I don't know if the time between events is enough to perform this update... anyone has got this issue before? how did you handle it?
Thanks
I want to receive an email when
1)The workflow will be successfully completed in time and a completion Notification will be sent to the respective person(e-mail id) or support group(distribution list) via the email task or the post-session e-mail notification in the session task.
The workflow will be continuing to run in excess of the expected time due to some issues (like network, data, etc).In such cases the “STILL RUNNING” notification will be sent to the respective person (e-mail id) or support group(distribution list) via the email task or the post-session e-mail notification in the session task.
For the scenario 1 just follow the guide linked by #rownum-highart.
For the scenario 2 use a parallel flow with a timer. Combine the two flows with Decision Task. Remember to use Treat the input links as set to OR. followed by Email Task with a condition of your session status.
so I am looking into the postmates API and I have been able to create a delivery. This was great, I also setup a webhook url with ngrok to test the response from postmates but I am totally stumped as to how to determine when the pickup was actually completed and the dropoff/delivery was actually completed.
I saved all of the responses in a database and each time I did the test delivery, I received exactly 70 calls from the webhook endpoint. And each time 47 of them were in regards to the 'kind': 'event.delivery_status'. Here are the stats:
THIS IS ALL IN TEST MODE WITH THE SANDBOX...
11 of those are 'status':'pickup_complete'
14 of those are 'status':'pickup'
11 of those are 'status':'dropoff'
11 of those are 'status':'delivered'
all of the webhook responses for status=delivered have a 'data.courier_imminent':false value.
I went to the webpage for the 'data.tracking_url' and when the webpage showed that the delivery was complete, I immediately updated the database to see how many records that I had saved and I was only at 32 total records. this means that the webhook was continuing to send me updates after it was supposedly complete.
Lastly, all of these statuses are not in order, they are totally random, in fact the 6th to last record that was received was a pickup_complete status..
The real question:
how will I know what is actually a picked=completed, delivered=complete etc..
You'll receive a webhook of type event.delivery_status. One of the field within the body of the payload will be {status: "delivered"}. This has been accurate so far. Postmates doesn't return adelivered_at` timestamp, but you could create your own timestamp and store it along with the delivery for reporting.
As for the number of webhooks, Postmates has a delivery robot (called robo) that moves as if it was a real postmate. You'll receive a lot of webhooks of type event.courier_update with the updated location.
my app has list of events with start time (date and time). I want to make a scheduled task to send reminder via email to all user participate in event 1 hour before event start. (Note: Admin can change time of event).
I currently use celery to send email to list of participants when admin change the time of event.
Please suggest me some solution for this. Thanks.
Here's a recent(ish) discussion where a potential solution is proposed for celery: https://github.com/celery/celery/issues/4522.
I built Posthook to make solving these kinds of problems easier for developers. In your case, when a new event is created or the event time changes you can schedule a request back to your app for 1 hour before the start time. Then when you get the request from Posthook you can send out the reminder after validating that it still needs to be sent out.
Given that I am a bit confused with CQRS I would like to understand it further in the following scenario.
I have an Actor that charge Users' credit card. To do so it contact a bank external service that does the operation, get a confirmation result. I would like to know how can I apply this with CQRS.
The information that needs to be written here is that a specific user has been charge a certain amount. So the event generated is Charged (UserID, Card, Amount). Something like that.
The problem is that all the examples I have seen especially with AKKA, would only generate the event after a Command is validated, such that it is persisted in a journal, and used to update the state of the actor. The Journal could then be red on the other side, such that to create a Reading view here.
Also usually, in those examples, the update state function has a logic that somewhat execute the command, because the command correspond straightforwardly to a state update at the end of the day. This is the typical BasketShoping example: CreateOrder, AddLineItem. All Of this Command, are directly translated in Event, that correspond to a specific code of the Update state function.
However in this example, one needs to actually contact an external service, charge the user and then generate an event. Contacting the external service can't be done in the update state, or after reading the journal. It would not make sense.
How is that done, and where, and when exactly, in the spirit of CQRS?
I can think of 2 ways of doing this.
First is a simple way. The command is DoCharge(UserId, Card, Amount). Upon reception of this command, you call the external payment service. If this has been successfully completed, you generate an event, Charged(UserId, Card, Amount, TransactionId) and store it in the journal.
Now, of course, it's not completely safe way, because your Actor can crash after it has sent the request to payment service, but before it has received and persisted the confirmation of the successful completion. Then you risk of charging the user twice. To overcome this risk, you have to make your payment operation idempotent. Here's how to do it. This example is based on the classic "RESTify Day trader" article. I'll summarize it here.
You need to split the payment operation in 2 phases. In first one, payment service creates a transaction token. It just identifies the transaction, and no financial operations are performed yet. Upon the creation, the identifier is received by your service and persisted in the journal.
In next phase you perform a payment associated with the identifier from phase one. If your actor now fails in the middle, while operation is performed successfully on the payment service side, the transaction token will already be marked as processed by the payment service, and it won't let you charge the customer twice. Now, if you restart the failed Actor, and it tries to run the payment associated with the existing transaction token, the payment service should return result like "Already executed" or such. Of course, at the end you also persist the result of the operation in the journal.