I am new to chatbots and using the wit.ai.
I had like to store user defined values for future use, such as Name of the user.
When the user says his name. It gets stored in a variable that can be used later.
Using entities limits me to a predefined list of names.
They have changed the getting started guide. Initially they showed the way to store user queries.
What you want to use is context object. It can store information which you want to pass on for later use. It is used to save the state of conversation.
In your story, click on Bot Executes, then an action to be executed at backend and finally type the variable name like username in the update context keys with field. This will make username available for use.
Related
I need to use credential for log in to a system in AA for a bot that may run on different machines with a technical user for the system associated to each machine/bot.
Lets say the system is Stackoverflow.
Lets say I have two Virtual Machines,named:VM1, VM2
I name my credentials "Stackoverflow-VM1", "Stackoverflow-VM2" and want the automation to dynamically access those credentials, so that running on VM1 the automation will always use the VM1 credential.
I cannot find out how to use such a machine-dynamic access in AA while this is easy to do in other automation softwares and credential vault seems to be pretty useless without this functionality, especially with the extra concept of lockers...Any help?
Already tried:
1) The credential variables in AA will look like this from the client: $Stackoverflow-VM1(username)$, so i tried to simply write (not using the F2 variable list): $Stackoverflow-$Machine$(username)$ into the Set Text field but that results in the string "$Stackoverflow-VM1(username)$" written into the corresponding text field, which is consistent with the AA documentation:
https://docs.automationanywhere.com/bundle/enterprise-v11.3/page/topics/aae-client/bot-creator/using-variables/credential-variables.html
"Credential variables contained in the Credential Lockers can be seen and accessed only from the Insert Variables window."
2) I tried to create different lockers, where VM1 will only see "Stackoverflow-Locker-VM1" and a corresponding locker for VM2 exists. Now if i could create credentials with the same name but different content in each locker i could easily do this, but i cannot create identically named credentials, since they are aware of each other and not only defined in the context of a locker.
3) This page suggests its not possible: https://apeople.automationanywhere.com/s/question/0D56F00005dy3Ri/can-we-able-to-use-credential-vault-dynamically-?language=en_US
but its a 8 month old thread and possibly it has changed now. Everything suggested in this thread is not possible in terms of scalability.
Thankful for any input,
Thank you.
First thing I would suggest that you should always use F2 to fetch the variable list.
Returning to the question, to me, it seems that you have a system where you want to log in using different devices (bot runners) using different credentials.
It is possible by creating provided credentials values.
When you create an attribute for any credential, there is an option to mark the value as provided. That way, the associated users will get the credential request.
Each user will have to provide their own set of values. The bot can be created using those credentials. At run time, based on the user who is logged in, appropriate values will be fetched.
Disclaimer: I work for Automation Anywhere.
I have read access keys on keen.io And I have a use case where I would like to use these access keys. Actually, in my system, i want to make a separate stream for every customer account and want to make sure that this stream is only accessible (could be written/read) by that specific customer only. I want to use access keys for this purpose as I think it is their one of main use cases.
Can anyone tell me how can I pass this information to an access key that it is only usable on a specific stream ONLY?
You would programmatically create an Access Key for each customer and set its permissions on creation so that it will autofill event properties with, for example, a customer id. With queries, you would set up the querying permissions with a filter so that it could only query event with that customer id.
Similar to the JSON in this example here: https://keen.io/docs/access/access-keys/#access-key-json-example
Then, any time that Access Key is used, it will only be able to query that specific data and all writes will include the autofill information that you set for that Access Key.
Is there a way to create a TimeEntryItem for another user?
I can persist the 'User' field before creating a new TimeEntryItem and see the User information being passed to Rally, but so far I get the following warning in the response, and the create request is treated as being for the calling user...
Warnings:["Ignored JSON element TimeEntryItem.User during processing
of this request."]
I don't think this is currently possible via the api. The warning you are getting above indicates that the User field is not writable, even on initial creation. So it is always just populated with the value of the current user making the request.
Is there any way to create user-dependent BAdI implementations? I mean that the BAdI has different implementations which are called depending on user which is logged and which calls the specific transaction.
Other scenario is to not call certain implementations for this user and to call for other user. Is is possible?
Now I'm using simple check
IF sy-uname = 'username'.
New BAdIs allow the GET BADI call to have one or more FILTERS parameters which can be used in the implementation definition to select different implementing classes. But these filter parameters must be provided by the code which calls the BAdI. When the standard code doesn't provide the username as a filter parameter, there is no way to choose an implementing class based on the username.
So when you want different logic for different users, you need to do this in your implementation code. But using the username to decide what to do might not be the most maintainable architecture.
I guess the reason why the BAdI is supposed to behave differently for a specific user is because that user has some special job in the company. What will you do when the person who has this position changes, or when he gets one or two other people to help them, or when he just calls in sick and someone else has to do his job? Do you want to transport a program change whenever that happens? But there are other options:
Different behavior by user group. You can read the user group from the database table usr02 (field CLASS)
Different behavior by permissions. Do an AUTHORITY-CHECK, and make the BAdI behave differently depending on the success.
Different behavior by user parameter. To read a user parameter in your program, use GET PARAMETER ID. The parameters of a user can be set by the administrators in the transaction SU03, by the users themself with the transaction SU3 (when they have the permission to do so) or programatically with SET PARAMETER ID.
I'm new to Redis and was hoping for a "best practice" solution to implementing the equivalent of a "users" table in a mysql database, for handling users in a web app.
Would I create a users SET in Redis? Or a users database with a SET for each user?
My standard setup for users is a serialized object in a standard key u:userid - this object gets retrieved on each request, and there is never any need to access only one of the properties.
You could also use a hash rather than json for the user properties, but my setup includes everything getting used as strongly typed objects and redis running on a different server from the client, so using json makes it easier to use generic deserialization and minimizes any latency issues.
In addition to the user object itself, you will need an index for any fields you need to use to find a user - for example to allow a user to log in with email address you will need a key e:email => userid. A hash will also work here - the important thing is that you need something that is O(1) to get from an email to a user object.
Sometimes parts of the user data should have their own keys - for example a followers list is a perfect match to a redis set, so is best stored in that form.
It really depends on what you'd want to do with the Users within your application. Another option would be to have each user be it's own hash, where they keys are properties (fields) for each user (firstName, lastName, etc). You could use a key that you increment as the ID generator for inserting, and potentially another set that you use to hold all of the user IDs.