There is any way to tell to watson that he sould reset the conversation "after this point everty asked will be just like conversation_start"?
tks
Watson conversation is stateless. So it doesn't know anything about where you are in the conversation without the context object.
To reset the conversation, you just don't send the context object, and it will generate a new one.
Or let's say you are in a process flow, and want to reset to a particular point. Just take a copy of the context object at that point in time. Then use that to rollback.
This is assuming that your application layer hasn't done anything outside of conversation which would be related to the rollback.
Related
As I’m developing my first corDapp, I thought it might be useful to be able to reference a transaction’s initiator(flow starter) from the contract level. The reason being that although my contract is callable by any party, I don’t necessarily want to allow any party to call each command.
In my state, I have a list of what you might call admins. These admins should be the only ones that are able to issue commands on this list like RemoveAdmin() or AddAdmin().
Instead of being able to reject this command from contract level (which I think should done at this level because this is just another command constraint) based on a reference of who initiated it, I have to instead do it on the responder flow level.
Anyone else think an tx.initiator field might be useful for permission constraints like I described? If not, why is it better to do it at the responder flow level?
I think the conceptual issue is that, in Corda, transactions can be collaboratively constructed - eg if two parties are exchanging assets and the partial tx gets passed around so they can populate it with their respective inputs. So there isn’t always a proposer/initiator conceptually. So the concept doesn’t exist on Corda’s data model.
That being said, you can take three approaches:
Since you don't care about who proposed the transaction, rather that it was done by an admin you can configure the non-proposing admins only to sign a tx if they see it has been signed by another admin. So none of the non-proposers will sign it until the actual proposer has.
Make the proposer/initiator of the transaction part of your State object and check that this proposer/initiator is in your Admin list.
Throw an exception if the initiator of the flow is not in the admin list:
//make sure that the party running this flow is already an admin
if(ourIdentity !in AdminInputStateRef.state.data.participants){
throw IllegalArgumentException("The initiator of this flow must be a admin.")
}
I understand, that random access in inefficient. But app failed, record content is (let's assume it) big for logging or otherwise inappropriate (that's true without assumption), so I only have info, that record at this offset failed and why. Good, now I want to see the data, let's say to be able to reproduce it. How to do that?
OK, I can use ConsumerSeekAware consumer, but that will rewind the position and process all records from that position on. I don't want that, I want just 1 specific message. I can use specific consumer in specific consumer group for this use case not to influence others and set ConsumerConfig.MAX_POLL_RECORDS_CONFIG to 1 so that each pull returns just 1 record, but this will not stop all records from reaching the listener. Since there is no way how to call poll manually, programmatically. Right? Or is there such a way? Or other how to achieve this? Even if I try to reach spring-kafka internals, the org.apache.kafka.clients.consumer.The consumer seems to be made inaccessible on purpose, or at least I do not see the way.
Yes, you can just create your own consumer manually and poll it.
Get a reference to the consumer factory and call `createConsumer("tempGroup", "tempClient").
You would need to create a second consumer factory with max.poll.records=1.
You can copy the other properties from the main factory by calling getConfigurationProperties() - and creating a new map from it and create a new DefaultKafkaConsumerFactory.
Close the consumer when you are done.
On our project, I store some data on block chain, my question is how can get to know when these data changed.(so that we can send emails, sms, web notifications to end user)
the first thought were list as below, but it seems either of them were best choice
query database every few seconds. Very stupid way, but it seems can be worked.
using one RPC interceptor, and check all the things send to node.
using flows, subflows
using schedule service
do you have any good ieads about this, please kindly reply me, thanks a lot.
Ok so a few points, there is no "real" blockchain on Corda, there are consumed/unconsumed states, I think you should reformulate a bit better your question, do you want to be notified when a states get consumed? When a new state is created? Try to explain in "Corda" terms :D
In a Watson's conversation to keep the context, do I need to send only the conversation_id every request? or the entire context object?
You need to send back the conversation_id and the system part of the context. The conversation ID uniquely identifies the specific conversation. The metadata in the system info has details about how long the dialog has been going on (how many turns) and in which dialog node you are. See here in the IBM Watson Conversation service docs for more information about maintaining state.
The context object also includes the user-specified data. That part can be wiped out or newly set on each turn.
What you can do is to first copy over the entire context object, then manipulate the user-oriented parts.
I'm implementing an Alexa search skill for a website. My question is that there is some kind of possibilities to give intents some kind of scopes, so built in Intents could be reused?
I mean, for ex. the AMAZON.YestIntent to have different functionalities on different situations.
You can handle this in your intent handler. You can save context information in the session or a database if you are using one. Then in the intent handler, test the session or DB data to determine which response to take.
For example, in the Who's On First? Baseball Skit skill, the dialog between the user and Alexa is about 85 lines long. The user can say "who?" at several different places in the dialog, and Alexa needs to respond differently depending upon which line of the dialog they are at. To handle this, I simply save the line number in the session. Then when an intent is called, the intent handler gets the line number session variable, uses it to select the appropriate response, and increments it and passes it along in the session for the next line.
It really depends on the complexity of your skill, the accepted answer is a perfectly correct implementation for a simple flow and it starts to address keeping state tied to the session.
If your skill is more complex and you're using Node.js, I would suggest using the official SDK which offers this functionality out of the box:
https://github.com/alexa/alexa-skills-kit-sdk-for-nodejs
The state management allows you to define which intents should be handled in each state and the rest can be passed to a context-specific handler. More information is here:
https://github.com/alexa/alexa-skills-kit-sdk-for-nodejs#making-skill-state-management-simpler
The state management takes a little getting used to, but once you have used it, you won't go back because of the control it offers you over the experience.