i really don't understand the difference between entry and do activities in UML state diagram
if i have state called create account and this state ask from user to enter his name,id and password
so enter name , id , password is entry activity or do activity ?
The difference is that the entry behavior is always run to completion, whereas the do behavior is only run to completion if no event triggers a transition. It will get interrupted by this event. Therefore, it could have an endless loop. If an effect-, do- or exit-behavior has such an endless loop, the statemachine will not react to events anymore.
As a sidenote: create account is not a good name for a state, since it contains an active verb. That is better suited for an activity. The state could be named creating account. The entry-behavior could be create account and this could include actions enter name, enter id and enter password. You should also model the possibility, that the users cancels the creation. Two completion transitions with guards [account created] and [canceled] could show what happens next.
Related
I have a question regarding the effect of eventually consistent (EC) microservice systems.
Imagine we have a booking system - a user-service A and booking-service B. Each service has its own database. Imagine the system does a concurrent booking of the same resource for distinct users at the same time. Lets assume we have a Runtime Verification System checking the concurrent booking.
Would it be possible that the monitor does not realize the concurrent booking at B, because the update in the database is done delayed because of the EC mechanism?
In your example, the Booking Service is the source of truth (presumably) for whether or not the resource is available to book. So, that service should be pretty clear on allowing the first booking request to happen and rejecting the second.
In a case like this, where "first come first served" is the requirement, you'd want an intermediate state that would wait for a response from the Booking Service and update the User Service only when a response has been received.
If your architecture is set up right, User Service shouldn't be calling Booking Service directly anyway - it should be communicating through a messaging plane. As such, when the User clicks "Book Now," you could generate a resourceBookingRequested message and submit it to the queue. You'd acknowledge this request has been queued to the user and update their UI to "Awaiting Booking Confirmation..." or something similar.
Once the booking is accepted, or rejected, the User Service subscribes to the resulting message and updates the UI (and/or takes other actions like sending an email) to let the user know their request succeeded or didn't.
I built the BookTrip bot from Amazon Lex detailed here.
When chatting with the bot the user can continue to book hotel rooms or rent cars until they end the conversation. Here is an example of a successful reservation followed by another reservation attempt through the chatbot interface:
When I use this chatbot in an Amazon Connect contact flow the user is not able to continue booking anything past the first reservation. Logically, the contact flow would keep executing the BookHotel or BookCar intents until the ConnectToAgent or EndConversation intents are executed.
I have tried looping BookHotel and BookCar back to the beginning of the "Get customer" input block but that errors out.
The best way to do this is keep the user in the bot until they have done all of their booking, and then exit back to Amazon Connect. You would do this in the following way:
Get slot values for initial booking
Use lambda to fullfil the intent (write to database, etc.) and clear the slot values
Use ConfrimIntent to as ask “would you like to add another booking”
If the user responds “yes”, confirming the intent then you would elicit the slot values (starting over at step 1)
If the user responds “no”, you would exit back to Amazon Connect
You can check out the lambda request and response details here
There is also a good discussion about this pattern on the AWS developer forum here.
I found one way around this that works for when you have multiple intents, though there are a couple drawbacks.
Basically, create a dummy block in Amazon Connect. I use Set Contact Attributes with a dummy attribute I named 'continue' with the value of 'continuing'. It is never used. Then on Success, loop it back to restart the Lex block!
No error when saving and publishing and works well for my use case.
Here's how the image above's set up works:
A. Play welcome prompt (this used to be the prompt when the Lex block initiated)
B. "Get customer input" is the Lex block.
C. Lex ends any intent and moves to dummy block (Set contact attributes)
D. On Success of setting dummy attribute, move back to restart B. Lex block.
Here are the drawbacks:
1. The Lex block requires some prompt when it initiates so you will have to design that into your bot, since it will deliver a prompt at the close of your intent, then another prompt at the restart of the Lex block.
2. This creates an infinite loop, at least until the user ends the call, or the session times out. One way around this though is to create an intent specifically for saying goodbye and don't point that intent fulfillment to the dummy block.
What I have implemented and successfully tested is adding "Greeting", "Yes" and "No" intents. When a real intent is fulfilled, I transfer the contact to the next Get customer input block that ask if the bot can help with anything else and checks for "Yes" and "No" intents. "Yes" transfers to the main Lex block. "No" obviously exits.
The key thing to me here is how do you set your text greetings so it doesn't seem confusing. Please see what I came up with on the flow diagram. Seems to be working to me.
P.S. Didn't test it in production.
I made a quiz skill where a user is first prompted with a response from Alexa asking if they are ready to proceed. From there, the user must either say yes or no to activate a corresponding AMAZON.YesIntent or AMAZON.NoIntent respectively. The quiz then begins, and a user says an answer letter followed by the answer for each question. I use a server to simulate state within my skill.
Normally I start my skill by saying:
"Alexa, start Quiz Skill"
But, I am finding that simulating state using a server does not make a very robust voice interface for the Echo. If a user says:
"Alexa, ask Quiz Skill yes"
The skill will jump to whatever I have setup to trigger when Amazon detects an AMAZON.YesIntent. This is not what I want! I want the user to follow the flow of the skill I have set out.
Is there a way to govern what intents can be activated at what time? A thought I had was to use attributes to basically set what intents are allowed to be invoked next.
There is a session object on each Alexa request. That session object has a new property that is either true or false depending on whether it's a brand new session for your Skill.
If you happen to be using the alexa-sdk node module to build your skill you can also use a NewSession handler to catch the new session and divert flow to what ever event/intent you want interaction to begin at. More on the state handlers can be found on the github page here
While I don't think it is possible to enable/disable intents, you can certain change how they respond. It's easy to use the session object to keep track of what the last intent spoken was. Then your intent handler(s) can read the session object to see what the previous response was in order to choose how to respond.
In your example above, you might save the last question number to the session object. If 'yes' doesn't make sense based on the previous (or lack of) question, then your YesIntent handler could respond with "I'm sorry, I don't know what to do with that", or even maybe just ignore it and start the dialog from the beginning.
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.
Here's the scenario. A user uploads an Excel file and this kicks off a workflow which validates the file, transforms it into a few different files, then performs an update to a database based on the transforms. After the uploads, the results need to be reviewed by team member before the flow can continue.
I'm using Ruby and have discovered that Signals and Timers are the way to achieve this in SWF. However, the Ruby examples are lacking or non-existent and I need a little help understanding how this would work using Ruby.
Ny understanding so far is that a Timer activity is scheduled which basically pauses the flow until either the timer expires (at which point I could cancel the workflow or email the staff and set another timer) or a signal is sent to the workflow to start the next step. The Decider would handle the signal and then kick off the appropriate activity.
Any thoughts or direction to other sources would be much appreciated.
Thanks,
Thomas
It's somewhat difficult to provide an "answer", given you didn't really ask a specific question. I'm in agreement with you that using a Timer and Signals is what you want.
You don't specify how the team gets notified about the review. I'll assume that you notify them by email and direct them to some website where they can review the changes, and then click on a link to either Approve or Don't Approve. Clicking the link to Approve will send a request to a web server that will "signal" SWF that the review has been approved. Clicking the link to Don't Approve will "signal" SWF that the review has not been approved. You mention that you want to renotify the team (or perhaps escalate to the manager) if no one has taken action on the review. Let's say this renotification happens after 48 hours. After the renotication, you grant them another 72 hours before assumming Don't Approve.
Here's how your workflow looks like to me:
User uploads file and kicks off a workflow
Decider Task schedules "TransformActivity"
TransformActivity runs, transforms the data into different files, and completes successfully
Decider Task schedules "UpdateDatabaseActivity"
UpdateDatabaseActivity runs, updates the database, and completes successfully
Decider Task schedules "EmailTeamActivity"
EmailTeamActivity runs, emails the team, and completes successfully
Decider Task schedules a Timer for 48 hours.
If a signal indicating Approve or Don't Approve is received within 48 hours:
Decider Task schedules the "RecordFinalDecisionActivity"
RecordFinalDecisionActivity will run, record the Approve (or Don't Approve) into the database, and complete successfully.
Decider Task will then close the workflow because it's done.
If no signal is received and the timer fires (after 48 hours):
Decider Task schedules the "EmailTeamAndManagerActivity"
EmailTeamAndManagerActivity runs, emails the team and manager, and completes successfully.
Decider Task schedules another timer for 72 hours.
If a signal indicating Approve or Don't Approve is received within the additional 72 hours given:
Repeat the same logic as the section "If a signal indicating Approve or Don't Approve is received within 48 hours".
If no signal is received and the timer fires (after the additional 72 hours):
At this point, the workflow can assume it was a Don't Approve, schedule the "RecordFinalDecisionActivity" and close the workflow once that activity completes.
The reason why you don't want to have a "review" activity is because that task gets scheduled and then some activity worker needs to reply success. How would that work? When someone clicks the Approve or Don't Approve link, the request to the webserver would have to pull down the activity from the task list. However, if the task list has multiple activities, SWF just gives out any one of them. It might not get the right one. Now, you could argue that you could schedule the different reviews across different task lists, but that's just cumbersome and tedious.
Signals are done to indicate an "external" event, which this very much is. The SWF documentation on Signals does a great job on talking about Signals. Here's the SWF documentation on how to use Timers and Signals. As for the particulars on how to use SWF and Ruby, I can't really help you there. I've only used SWF with Java by using the AWS Flow Framework.
user upload excel file, does "StartWorkflowExecution", that queues a decision task
decision worker notice flow is new / "stage one", it schedules "transform file" activity task
activity worker picks up task, and does the "transform file" activity, when done does "RespondActivityTaskCompleted" with a result of "transformations done", that queues a decision task
decision worker picks up decision task, notices the transformations are done and schedule a new activity task
activity worker picks up activity task, notices it's for a team member (according to the instructions given by the decision worker when scheduling the activity task), team member gets notified, somehow perform his action, then somehow notifies the activity worker which will reply "RespondActivityTaskCompleted"
I don't see the need for a Timer or a Signal, it's just plain flow. Those two concepts are useful if you want recurring events, timeouts, and/or interrupting the flow.
Please note that you can differentiate activity workers by using task lists (for example activity workers for automated work vs activity workers for human participants, whatever).