Making chatbot that can giving response base on time - aiml

I'm using program-o to develop my chatbot on my own website
Let's say if I type "good morning" to my bot at night, the bot will still respond to me "morning".what I want is if I type "good morning" to my bot at night, the bot will respond "current time is 9pm, so you shouldn't use morning ".Is there any possible solution to this kind of problem?

Yes, you need to look at the <date> tag and check its contents. I answered this question here:
AIML Chatbot response differs at different times?
By coincidence, I also posted a category that handles "Good morning".

Related

AWS How can I implement check back questions for my Amazon Lex Bot?

Currently I have many intent questions and lambda functions which answer those user questions by taking answers out of my DynamoDB. Now there are some answers which require a back questions to the user e.g. user asks "How are you", Lex Bot answers "I am fine. How are you", user answers "I am fine, too". Now Lex Bot should actually recognize that the user answered his question and should say something like "Cool" or "Very nice".
Is there some possibility to implement such a back-answer-handling?
I don't want to have some intent saying "I am fine, too" as this is really ugly and would not always be fitting :/
**Edit: If something is unclear in my question, please just ask me. Thanks!
Initially call your Lambda in the initialisation and validation phase, and return the the Lex response with a DialogAction of ElicitSlot, so you can then pick up the second response ?

Google Action showing Invocation Error instead of triggering Fallback intent

The scenario:
I have a google action that is used to deliver voice surveys. It is controlled by dialogflow ES and has two main intents. A welcome intent and a fallback intent. The welcome intent is used to detect the name of the survey that user would like to open and this is stored in a parameter called "surveyname". "Surveyname" is then passed to our webhook where the survey is opened, the user is welcomed, and initial question is asked. All other subsequent interactions are picked up by the fallback intent, which calls our webhook which controls the flow of the survey and provides the google action with the subsequent questions. The subsequent interactions could include any phrase as I could have a survey asking any question on any topic.
The problem:
Up until extremely recently, my google action worked perfectly fine. But I have encountered a problem where the Google Assistant App will on occasion forcefully leave the action and exit the conversation. For example a user may input "yoga", and Google Assistant will leave the conversation and do a google search for yoga. When I test this phrase in the "Test" page of the action console I can see no request or response body, only "Invocation Error". Along with the message "You cannot use standard Google Assistant features in the Simulator. If you want to try them, use Google Assistant on your phone or other compatible devices." When I test in the "Try it now" box in Dialogflow ES itself, I can see the correct fallback intent, webhook request, and response. But I cannot see the phrase that was said in the Google Assistant app in the "History" tab of Dialogflow ES; it looks like it never made it that far. This suggests to me the problem is with either Google Assistant or the action itself, rather than Dialogflow.
Invocation Error
The current (less than ideal) work around:
I understand that fallback intents have a lower priority that regular intents. I believe there is an internal tussle going on between the fallback intent and Google's implicit invocation. My current temporary solution is to create a new intent called ActiveSurvey, and with this custom intent hope to capture some of the input phrases that are being missed by the fallback intent. This appears to work somewhat, but I can't ever hope to capture all input this way, as the user could quite literally say absolutely anything. Considering it used to work, in my mind this shouldn't be necessary.
The questions:
Why has this happened now?
Is there some setting I'm missing that has caused this to happen?
Or is the design of the action incorrect?
Any help much appreciated thank you.
Starting in October 2020, and expanding further in January 2021, Google began implementing a feature called no-match yielding, although this was not listed in the documentation until February 2021.
Under no-match yielding, Google will close the Action and handle it itself if both of these conditions are true:
You are handling it through a Fallback Intent in Dialogflow or through a No Match Intent in Action Builder and
The phrase is one that the Assistant can handle itself
The workaround for this under Dialogflow is to have an Intent with a single phrase with a parameter that matches the #sys.any System Entity type and to use this Intent (and the parameter) for your processing instead of a Fallback Intent.
Fallback Intents should only be used in cases where the user input cannot be routinely handled (ie - you want to say that you didn't understand, or it is an error).

Recursive Alexa Response with DynamoDB

so I am basically trying to tell an interactive story with Alexa. However, I am not sure how to edit an intent response while being said by Alexa. This should happen in a way, that keeps it updating while Alexa tells the story.
In my scenario Alexa is only one daemon fetching strings from DynamoDB and while new story lines are being generated she is supposed to read and then tell them as soon as they're processed. It seems that Alexa needs completed Strings as a return value for its response.
Here an example:
User: Alexa, tell me a story.
Alexa: (checks DynamoDB table for a new sentence, if found) says sentence
Other Device: updates story
Alexa: (checks DynamoDB table for a new sentence, if found) says sentence
...
This would keep on going until the other Device puts an end-signifier to the DynamoDB table making Alexa respond a final This is how the story ends output.
Has anyone experience with such a model or an idea of how to solve it? If possible, I do not want a user to interact more then once for a story.
I am thinking of a solution where I would 'fake' user-intents by simply producing JSON Strings and pushing them through the speechlet requesting the new story-sentences hidden from the user... Anyhow, I am not sure wether this is even possible not to think of the messy solution this would be.. :D
Thanks in regard! :)
The Alexa skills programming model was definitely not designed for this. As you can tell, there is no way to know, from a skill, when a text to speech utterance has finished, in order to be able to determine when to send the next.
Alexa also puts a restriction on how long a skill may take to respond, which I believe is somewhere in the 5-8 seconds range. So that is also a complication.
The only way I can think of accomplishing what you want to accomplish would be to use the GameEngine interface and use input handlers to call back into your skill after you send each TTS. The only catch is that you have to time the responses and hope no extra delays happen.
Today, the GameEngine interface requires you to declare support for Echo Buttons but that is just for metadata purposes. You can certainly use the GameEngine based skills without buttons.
Have a look at: the GameEngine interface docs and the time out recognizer to handle the time out from an input handler.
When you start your story, you’ll start an input handler. Send your TTS and sent a timeout in the input handler of however long you expect the TTS to take Alexa to say. Your skill will receive an event when the timeout expires and you can continue with the story.
You’ll probably want to experiment with setting the playBehavior to ENQUEUE.

Can Amazon Alexa Skills Kit (ASK) detect where it was interrupted (if it was)?

I want to write an Alexa skill that would read a list of items out to me and let me interrupt when I wanted and have the backend know where I was in the list that was interrupted.
For example:
Me: Find me a news story about pigs.
Alexa: I found 4 news stories about pigs. The first is titled 'James the pig goes to Mexico', the second is titled 'Pig Escapes Local Farm' [I interrupt]
Me: Tell me about that.
Alexa: The article is by James Watson, is dated today, and reads, "Johnny the Potbelly Pig found a hole in the fence and..."
I can't find anything to indicate that my code can know where an interruption occurs. Am I missing it?
I believe you are correct: the ASK does not provide any way to know when you were interrupted, however, this is all happening in real-time so you could figure it out by observing the amount of time that passes between doing the first ASK 'tell' (ie. where you call context.success( response )), and when you receive the "Tell me that" intent.
Note that the time it takes to read in US-en could be different then for US-gb, so you'll have to do separate calibrations. Also, you might have to add some pauses into your speech text to improve accuracy since there will of course be some variability in the results due to processing times.
If you are using a service like AWS Lambda or Google App Engine that add extra latency when there are no warm instances available, then you will probably need to take that into account.

Webservice on Navision / Microsoft Dynamics version 5... or else?

Go bounty!
This question has earned me a tumbleweed badge (7 views in 7 days!), which is somehow a strong confirmation that Navision has a very limited market share, which - I suspect - should be a confirmation Navision is neither all that great piece of software...
But hey... that's what we got as a back-end, so I am ready to fight with this. :-O
If there is some daring navision developer who is able to shed light onto this... the bounty is there for you! :)
Original Post
I have recently implemented a rather complex e-commerce system that interacts with a legacy back-end based on Navision 5. So far the exchange of data between the two platform has happened via XML files, but this method is quite clumsy and very much prone to mishaps.
Our needs are:
To expose certain elements of the business logic of each platform to the other one (for example: "what's the total amount ever purchased by this customer?", "what are the products currently on offer?", "how many new customers have registered on the website?", etc...).
To have mechanisms of feed-back / validation for the various transactions (for example: "Here's the a new order from customer X" ... "Ok, got it, the order will now start to be processed" ... "Ok, copy that, bye!").
If possible, avoid playing around with files, but keeping all of this happening in terms of calls/ports/services...
The most natural way I could think of would be to integrate the two systems via webservice, but Navision 5 does not support this natively. So I did my "due diligence" and found a few things on MSDN including this article and this other one.
According to these articles it should not be that difficult to create a webservice on Navision 5, but when I suggested this solution to the team in charge of the legacy system, they told us that it is "pure theory" and they do not know of anybody who ever implemented it.
I have no reason to doubt their word, but mileage can vary... and I thought that maybe in the SO community there are professionals from other countries who actually implemented something similar and are available to share their experience.
So, my question is two-folded:
Is there anybody who has tried this at home and would be available to share a bit on what have been the greatest difficulties, if the final result is reliable, if they think the outcome is worth the effort, etc... ?
Is there anybody who faced a similar problem but solved it with a different approach and that would be available to present their solution ("I never did it myself, but if I had to do it I would do it like this..." type of answers are also welcome)?
Thank you in advance for your time! :)
I too will chime in with a not-too helpful answer about Nav 6 :)
I've just completed a project using Nav 6. Suprisingly, the webservices are VERY easy to expose and consume. It's really a trivial matter to go find a object in the webservices interface and tick a box to tell it to expose itself.
Unsuprisingly, the webservices don't work as you'd expect, you have to often use some trial-and error to get objects and properties to persist, as it's really touchy as to the sequence of events you use to save and object. And each object seems to work slightly differently. eg: To create a customer, I eventually found out that you have to create and save a blank customer, massage this new record with a codeunit, then fetch the record and then write the customer's attributes and save again. I expected to just create a new customer(), set the attributes and save in one quick swoop.
I guess you're not too keen on upgrading to Nav6, but off the top of my head, Here is how you could simulate web services:
Sharepoint can already consume and expose webservices, so that tier isn't a problem.
Nav 5 doesn't have them 'naturally', but you could cook up your own program that acts as a webservice 'broker' - you're already getting info into and out of nav, via mostly XML. You could build this broker to take input as the xml files and massage them to use in a webservice call. You could even forgo the XML and write and read directly from the Db, as all the Nav info is stored there anyway. So here's what I'm thinking:
NAV <-> SQL SERVER <-> New 'broker' webservice <-> Sharepoint
Or if you already have the NAV API down pat and want to resuse your XML:
NAV <-> XML files <-> New 'broker' webservice <-> Sharepoint
If you are using XML and use filewatchers, the latency shouldn't be too bad, usually filewatchers pick up on a drop or change in milliseconds.
Hmm, but I'm thinking you are probably supposed to use BizTalk for stuff like this:
NAV <-> BizTalk <-> Sharepoint
But I don't know how easy it would be to set up BizTalk to communicate with Nav. I'll bet that it's pretty straighforward to get comms working, but this is speculation.
In any case, I don't know how helpful this post is, but maybe it gives you a few ideas to go with.
Cheers,
Lance
Where I work, we were able to use one of the web services from NAV 6 to integrate with SharePoint, so you can look up a customer or record and show it in a web part in SharePoint. I know your question is about NAV 5 in particular, but I have only seen this working on NAV 6. And I wasn't the developer who worked on this, so I don't have any more specifics I'm afraid.
Did you try asking on mibuso.com? They're much more Navision-focused.
When you say expose business logic, does this include executing AL code (e.g. a CodeUnit)? If you only need to perform queries against the database you could use NODBC & System.Data.Odbc or the CFront .NET API. Either of these can easily be wrapped using a .NET web service, and both support the native NAV database. To pass messages back you would still need to use COM, as described in the first article you mention.
Any of the above are entirely possible, and relatively easy depending on your proficiency in .NET, COM and NAV.
The second article you linked to describes using the NAS. I'm no expert on this, but I think this might require a special license granule. Before spending time implementing anything its worth checking whether your license includes the NAS, CFront or NODBC.
You can actually do a "technical upgrade" of NAV 5 to NAV 2009 and then use the native webservices. Meaning replacing the exe-files and the entire application (but not the objects, which will still be version 5), and a couple of other tricks. But it works, and thus you have 2009-webservice-functionality on your NAV 5 :-)
For the benefit of anyone googling this, if you're still on Navision 6 with the native database, a good way of connecting it is via the windows message queue.
You can write your own web service that puts XML requests into the queue and then wait for the reply to pop up. On the Navision side, you have one clients that pulls the queue and puts answers into the reply queue. There's a special non-GUI client called NAS for that.
I've been using this approach for 15 years to connect booking engines to out Navision back end. It works very well and has the advantage that you can peek at requests before they reach Navision, so you can protect your back end from too many or faulty requests.
The only problem with this approach is that the COMMIT command within Navision is super expensive. It's difficult to serve high volumes of requests. As soon as the back end needs committing, you are down to just a few requests per second. This may be fine for low volume.
For high volume you need to implement caching or getting some of the business logic out. For me it was getting hit by price comparison websites, so here the solution is serve those from web services written in Python and only pass on the requests if someone buys something...