Here are the details of the error I am facing with dialogflow CX
My bot is designed to go to different flows from the start page and from each flows it goes to anything else flow and back to start flow.
Recently, I have noticed that if we call a flow more than 3 times in same sessions, we get below error the 4th time:
More than 10 nested flow transitions detected
This also happens when we go to any 3 flows and same error occurs while performing the 4th task.
I encountered the same problem, and upon a bit of research I found a workaround. The problem is that by going from flow to flow you're not "closing" them and dialogflow finds itself in a 10 levels nested conversation: to solve it you need to close the flows each time you go anywhere else.
By default, Dialogflow will try to stick to a conversation flow until it reaches the end. If, while in conversation, you go to another flow it follows the pages until the end of the flow and then gets back to the last visited flow and goes on until it finishes that one too, and so on until and "End Session".
This allows you to build complex conversations with deviations from a "main path" but is more difficult to handle when you have multiple "main paths".
I had originally designed my bot to behave as yours, and got the same error, so I had to change strategy. I did as follows:
Created a "Main flow" which had route groups going to all other flows and a few management pages (follow-up for certain questions, onboarding, profanity handling and so on). This flow was stationary, meaning that when you are in a given page you can't actually go anywhere else in the flow, only to other flows by means of route groups. If the user says Goodbye I end the session and that's all.
Changed all other flows to go to the End flow page instead of going to the "main flow". This prevents dialogflow from encountering the error you're mentioning. Each flow now has its own pages and conversation, but when the task is finished instead of having a route going to "Main flow" you have a route going to "End flow". This allows dialogflow to close the flow you're using and not having, as you posted,
More than 10 nested flow transitions detected
So now, each time the conversation starts:
you go to the main flow;
then based on what you tell the bot you go to another flow (handling
that intent);
When you reach the end of that flow (perhaps you have
completed and order or requested assistance), there is a route going
to the "End flow" page (builtin).
This brings you back to the last flow you've visited (in our case the "main flow").
From here, you handle another intent, and so on until you go to a page "End Session" and the bot is closed.
The only thing you need to test is that you can't jump from other flows to other flows, but each flow is only accessible from the main flow (this will avoid being stuck inside the conversation).
Related
I am currently exploring Dialogflow CX and struggling to create a simple entry message to greet the user.
I googled and found this, conceptually i can understand it, but i am having difficulty to implement the concept.
Hoping that anyone here can help with this. Thanks
I opened the link you posted and understand your doubt. I'm guessing what you're referring to is this sentence: "Propagating intents is useful to create an entry message for a flow's start page (transition target flow's route has a fulfillment)."
I have two considerations:
If your goal is simply to create an entry dialogue for a page, or flow, ignore this passage in the documentation and just use the entry dialog option on a page as shown below. Note that only pages which are not Start can have an entry dialog: if you'd like to add an entry dialog to a flow just create a new page in that flow, add routing from the Start page to your new page with the custom expression "true" as shown here and then add the dialog:
On the other hand if you're interested in intent propagation it simply states that whenever you match an intent, that is forgotten at the next step in the conversation, because another intent or condition will be matched. The only exception is if you mean to route the conversation to other flows or pages: until you reach the final "destination", the intent just matched will be remembered in the intermediate jumps and can be used in conditions for example. So say that if intent I_Want_Chocolate is matched in page Book_table of flow Restaurant_Reservation, you want the conversation to move to another flow, Vending_Machine: if the start page of flow Vending_Machine has a condition based on intents, your I_Want_Chocolate will be remembered even if the user started in another flow/another page: in this way you can for example create multiple pages and have Vending_Machine route to pages ChocolateOrder, CandyOrder, WaterOrder without asking the user again what it is they want.
Hope this cleared it up!
I am trying to build a Dialogflow agent for something like StackOverflow, where it takes care of the user asking a complete question. I want to store the answer (and feed it back to the user). For example:
User: "I get an error."
CX: "Which error?"
"Java.lang.NullPointerException"
"Okay, what have you tried so far to solve this problem?"
"I googled it but found no results..."
"On what line of code do you get the error?"
"if (running) {counter ++}"
"Okay, so to summarize:
- You got the error Java.lang.NullPointerException
- You tried: I googled it but found no results...
- You got the problem on the line of code: what line of code do you get the error?
Is that correct?"
With no 'Fallback Intent'-hack available in CX; how would I go about building a bot with open ended questions?
Here is the following response to your comment How to build a Dialogflow CX agent with open questions?
To work with open ended (meaning: open answers that cannot be categorized into intents / parameters) questions, and store answers, you can use the same approach provided in my previous response, and utilize the “sys.any” entity and parameters.
To do this:
When you create an intent for the utterances, annotate the
utterances to the “sys.any” entity. Here is a sample for your
reference:
You can change the name of your parameter-id to distinguish the parameters that you will use in each page.
Add those parameters on each page. Here is the sample for your
reference:
Continue applying Step 1 & 2 to your other intents and pages for the
collection and storage of answers to your open-ended questions.
When you have reached your final page, you can reference your
parameters in the responses through this format:
$session.params.parameter-name. Here is the sample for your
reference:
You can check out reference session parameters for more information.
When this is completed, this is how your use case similarly looks like:
To build a bot with open ended questions in Dialogflow CX, you can utilize the Flows and Pages features.
As an overview, Flows are used to define your topics and its associated conversational paths. For each flow, you can define many pages, where your combined pages can handle a complete conversation on the topics the flow is designed for.
You configure each page to collect information from the end-user that is relevant for the conversational state represented by the page.
Once a page becomes active, the agent follows several steps which may involve entry fulfillment, pre-filling forms, state handler evaluation, form parameter prompting, sending response messages to the end-user, and either a page change or a repeat loop.
For your use case, you can create a flow for the user getting an error and pages for the error details.
To do this:
Create an intent for the utterance “I get an error”.
Add this intent as an intent route in your flow.
In the same intent route, create a new page for the error.
Under the Page’s Fulfillment, you can add your response as shown
below:
This approach will leave an open ended question. See the test result below:
Continue the flow by creating another intent for the utterance
“Java.lang.NullPointerException”.
Add the intent as an intent route in your page for the error(As an
example: The page for the error is named “Error Types” and the
intent name in Step#5 is “Java Error” as shown below):
In the same intent route, create a new page for the
“Java.lang.NullPointerException” (As an example, the page named is
“Java Error Type” as shown below):
Under the Page’s Fulfillment, you can add “Okay, what have you tried
so far to solve this problem?” as the response.
Continue the flow by applying the same approach to your other open
ended questions.
When this is completed, this is how your use case similarly looks like in the visual builder:
See the test result below:
After moving over from Bot Framework v3 and studying the docs/samples, I'm still not understanding why the WaterfallStep dialog handling in v4 was implemented in such a way.
Why was it chosen to process the result of the previous step in the next step within a waterfall?
Given a waterfall with 3 Steps PromptName, PromptAge and PromptLocation, I see the following:
Method naming: Given the 2nd and 3rd prompt, method naming gets unclear. Naturally we would do AskForAge() or AskForLocation() but this is misleading due to the next point
SOLID Principals: Isn't "single responsibility principal" violated as we do two things in each step? Storing the previous response while asking for the next one in the same method, which ultimately leads in method names like AskForLocationAndStoreAge()
Code duplication: Due to the fact that each step assumes concrete input from its previous step, it can't be reused easily nor can order be changed. Even the simplest samples are hard to read.
I'm looking for some clarification on why the design was chosen this way or what I have missed in the concept.
This question seems largely opinion-based and therefore I don't know that it is appropriate for Stack Overflow. It turns out there is actually a good place to ask these kinds of questions, and it's the BotBuilder GitHub repo. I will attempt to answer it all the same.
Why was it chosen to process the result of the previous step in the next step within a waterfall?
This has to do with how bot conversations work. In its most basic form, without any dialogs or state or anything, a bot works by answering questions or otherwise responding to messages from the user. That is to say, a bot program's entire lifespan is to receive one message, process it, and provide a response while the message it received is still "active" in some sense. Then every following message the bot receives from the user is processed in the same way as though the first message was never received, like the message is being processed by an entirely new instance of the program with no memory of previous messages.
To make bot conversations feel more continuous, bot state and dialogs are needed. With dialogs and specifically prompt dialogs, the bot is now able to ask the user a question rather than just answer questions the user asked. In order to do this, the bot needs to store information about the conversation somewhere so that when the next message is received from the user the new "instance" of the bot program will know that the message from the user should be interpreted as a response to the question that the previous instance of the program asked. It's like leaving a note for someone working the next shift to let them know about something that happened during the previous shift that they need to follow up on.
Knowing all this, it seems only natural to process the result of the previous step in the next step within a waterfall because of the nature of conversations and dialogs. In a waterfall dialog containing prompts, the bot will receive messages pertaining to the last message the bot sent. So it needs to process the result of the previous step in the next step. It also needs to respond to the message, and in a waterfall that often means asking another question.
Isn't "single responsibility principal" violated as we do two things in each step? Storing the previous response while asking for the next one in the same method, which ultimately leads in method names like AskForLocationAndStoreAge()
As I understand it, the single responsibility principle refers to classes and not methods. If it does refer to methods, then that principle may well be violated or bent in some way in this case. However, it doesn't have to be. You are free to make multiple methods to handle each step, or even to make multiple steps to handle each message. If you wanted, your waterfall could contain a step that processes the result of the previous prompt and then continues on into the next step which makes a new prompt.
Due to the fact that each step assumes concrete input from its previous step, it can't be reused easily nor can order be changed. Even the simplest samples are hard to read.
You ultimately have control over how the input is validated/interpreted so it can be as concrete as you want. The reusability of a dialog or waterfall step has everything to do with how similar the different things you want to do are, the same as in any area of programming. If the samples are hard to read, I recommend raising issues with those samples. Of course, you can still raise an issue with the design of the SDK itself in the appropriate repo, but please do consider including suggestions for the way you think it should be instead.
I’m a beginner at Camunda/BPMN and I want to use it to control what is going on in nodejs, mostly likely using a REST API, at least for now. (Unless folks have a better idea for how nodejs should talk to Camunda.) My goal is to deliver systems where non-programmers can update the business logic in very practical ways.
I'd like to trigger the start of perhaps more-than-one process by sending a REST message, say to reflect that "a new insurance policy has been sold" and that might trigger the instantiation of say 2 processes on Monday but perhaps on Tuesday we add a third and now the same REST API call should now trigger more activity on Wednesday. (I figure it is better for nodejs to know about events but not about the process definitions. After all, my goal is to use Camunda as a sort of business logic server for my application. The less the nodejs code needs to know, the better.)
Which REST API should I be using to express the message that, say "a new insurance policy has been sold"? When I look at:
https://docs.camunda.org/manual/develop/reference/rest/signal/post-signal/
I find it very confusing. What should "name" match in the biz process definitions? I assume I don't need an executionId? I assume I can leave out tenantId?
Would some string in the message match the ID of a start event in one or more process definitions (or what has to match what)?
When I look at a process, is there an easy way to tell what variables I need to supply to start that process running?
Should I perhaps avoid using this event-oriented style of kicking off processes and just use the POST /process-definition/key/{key}/start? It would seem to me to be better form to trigger activity with events or signals or something like that rather than to have my nodejs code know about the specific process definition by name.
Should I be using events or signals in this case?
I gather that the start event should not be a "None Start Event" but I'm not clear on what type of start event TO use if I want automatic triggering based on events or signals or something? Would a "Non-interrupting - Message Start Event" be the right sort? I'm finding this confusing.
Once I have triggered the process to start, what does nodejs need to send to step the process forward from one task in that instance to the next?
Thanks!
In order to instantiate a new workflow instance you have the following possibilities:
Start exactly one instance:
Start a workflow instance by its known "key": https://docs.camunda.org/manual/develop/reference/rest/process-definition/post-start-process-instance/
Start a workflow by a message start event: https://docs.camunda.org/manual/develop/reference/rest/message/post-message/. A message can only start one specific workflow instance, it is not allowed that this is not a unique relationship. The message start event is the one you have to use in your BPMN process model. See also https://docs.camunda.org/manual/develop/reference/bpmn20/events/message-events/. This might indeed be the better approach to make your client independent of the process definition key.
Start multiple instances:
- Start a workflow instance by a BPMN signal event: https://docs.camunda.org/manual/develop/reference/rest/signal/post-signal/. The signal name could start many instances as once.
The name of the message or name of signal would be configured in the BPMN model. Both could work for your use case.
Once a process instance is started it will move automatically execute the next steps.
Probably following this example (https://blog.bernd-ruecker.com/use-camunda-without-touching-java-and-get-an-easy-to-use-rest-based-orchestration-and-workflow-7bdf25ac198e) step by step can give you some better idea?
I'm making some study of eventsourcing before applying it (or not).
Quick question : When using EventSourcing pattern we can imagine this scenario to handle an event :
command sent
command handler receive the previous command, validate it then
command handler persist this event and publish it
business model apply (business logic algorithm v1 for example) this event mutating its internal state
We can replay all the events and reconstruct the business object state.
How to handle business logic bugs (business logic algorithm v1 contains a nasty bugs).
I read we can fix the bug and replay the events and then we got the business model in a valid state once again.
But what happens if when fixing the business rule when applying event#1 would have caused the 'futurs' commands to fails ? In other words, the event#2, event#3, event#n was dependend of the state of the domain model after applying event#0. How can we fix the cascading events failure ?
I don't have a specific usecase : but we can imagine an account where balance is currently positive. Applying Event#0 increment the balance but this was a bug, the developer wanted to reduce the balance. Event#1 is a purchase that was valid because of the positive balance at this time.
The developer fixes the bug and replay the events. Event#0 decrease the balance which becomes negative. Event#1 is replayed : what happens ?
Do we need to handle this case with 'compensation' ? how ?
thanks in advance for your comments, external ressources that can be of any help (articles, blogs).
bye
Minor correction
When using EventSourcing pattern we can imagine this scenario to handle an event
command sent
command handler receive the previous command, validate it then
business model verifies that the command can be satisfied without violating the business invariant, and calculates the ensuing events
command handler persist this events and publish them
The command handler (specifically, the anti-corruption layer) is responsible for making sure that the command is well formed. The business model decides if the command is permitted by the business.
The good news: the events are just state changes; all of the rule validation is already done. When you fix the bug in the domain object so that it produces the correct events in response to the command, you aren't changing the way the event is applied.
And you certainly aren't changing the history -- if the ATM gave away $20 that it wasn't supposed to, you can't get the money back by editing the record.
What that means is that deploying the bug fix keeps the problem from getting worse; but it doesn't do anything for the event histories that are incorrect.
Compensating events are the right answer here. Ever have a grocery clerk double scan an item, and have to back one of them out? If you look closely, you'll see all three items
+1 candy bar
+1 candy bar
-1 candy bar
That's the idiom of the compensating event being appended to end of the stream.
So if the error showed first appeared in event #0, and then [event #1 .. event #99] have been played on top of that, the remedy for the error is to publish a compensating event #100.
Notice that this is exactly what book keepers would do. You put the wrong sign on the entry on line #1, add a bunch more entries, realize your mistake, and add a new entry that compensates for the earlier mistake.
More good news: in mature business processes, there are already mitigation procedures in place to handle various contingencies. So you can grab a meeting with your domain experts, and doodle on the whiteboard explaining the problem, and your experts should be able to show you the right way to compensate for it. Everything after that is feature management (does the mitigation need to be automated? Does the system need to do the mitigation automatically, or can it let human experts tell it what mitigation to apply, etc. etc.)