I am working on WIT Chat Bot... i have a story, in that i am asking for the quick replies Yes or No. if user press Yes or No. I have to make another call on WIT with context. So how can i set quick replies into context. how to handle quick replies.
i have tried for another contexts i am updating context like below..
context.getContext().remove("reasons_cancellation");
context.getContext().put("cancelbutton_pressed", true);
but i am not sure with quick reply keys and possible values
If I understand you correctly, you are looking to handle yes_no entity of quick replies feature in wit.ai.
In case of handling quick replies like yes/no, you would need to add 'Yes' and 'No' as quick replies to very latest 'bot says' statement.
After that, you need to have Yes & No as User's next response statement. Note, Yes & No would need to be shown as branch. In user response of yes/no, use yes_no entities with value of yes or no in respective branches.
Once this is specified, specify an action with a name. yes_no entity will be passed to the action. In your action implementation (your server side logic), you need to retrieve value of yes_no entity, use it and assign the value in context when needed.
Hope this helps.
Related
I went through the Merge Tags here and here, but couldn't figure out the syntax that would allow me to show content based on whether the user has certain Tag or not.
Help?
My goal in case it helps:
User subscribes, and is queued for a welcome mail one day later. In meantime that user may get tagged (my way of segmenting them), and so, the next day when that user receives the welcome mail, the content needs to be catered based on the tag that user got.
Got a response from their support saying
merge tags do not work with Tags just yet
here's the whole thing:
While we do have conditional merge tags available, I'm afraid we do
not have any that would work with Tags. To be transparent, Tags were
recently added a few months ago, and there are some features in our
application that has not updated to work with Tags just yet.
Because conditional merge tags do not work with tags yet, the best
option would be to create multiple automations and send them out based
on each tags. If you do it that way, you'll be able to target those in
specific tags with specific content
Dug a little deeper from the first link. There is another link Use Conditional Merge Tag Blocks which contained the below code:
Name
IF-ELSE
Definition
Use ELSE to indicate alternative content to display if the *|MERGE|* tag value is false.
Example
*|IF:MERGE|* content to display *|ELSE:|* alternative content to display *|END:IF|*
Name
ELSEIF
Definition
Use ELSEIF to specify a new *|MERGE|* tag to be matched against if the first *|MERGE|* tag value is false.
Example
*|IF:TRANSACTIONS >= 20|* Enjoy this 40% off coupon! *|COUPON40|*
*|ELSEIF:TRANSACTIONS >= 10|* Enjoy this 20% off coupon! *|COUPON20|*
*|ELSE:|* Enjoy this 10% off coupon! *|COUPON10|* *|END:IF|*
More examples with definitions can be found here.
Hope this is the answer you were after.
I am using the user exit USEREXIT_SAVE_DOCUMENT_PREPARE to check some positions in a delivery for some specific criteria.
I just want to do this whenever PGI is triggered. For this I use this condition in the user-exit:
IF ( sy-tcode EQ 'VL01N' OR
sy-tcode EQ 'VL02N' ) AND
sy-ucomm EQ 'WABU_T'.
But now I am afraid that this is not enough for cases like:
booking the exit directly from vl02n (without checking the positions)
book the exit via "Edit --> Post Good Issue"
editing the positions and book
Are there some further options which can be checked to make sure that there is a booking?
How can I make completely sure that a post of goods was triggered in fact?
You can try to utilize Workflow to cover all possible cases.
Create Workflow event which will be triggered upon delivery creation/change and check for Post Goods Issue there. Delivery BO is LIKP so go to tcode SWU_EWCD and enter data like this
Workflow events are based on change documents so every times smth is written to the table it will be fired. Check that your event is properly created in SWEC transaction.
You can also create events based on NACE conditions. After that use your event to generate your own workflow.
Also BAdI LE_SHP_DELIVERY_PROC may be of interest for you, it has method
SAVE_AND_PUBLISH_BEFORE_OUTPUT which is executed before saving of delivery.
You have to check value in T180-TRTYP. If value is 'H' then it is create booking otherwise it is change booking.It is better to remove transaction code and sy-ucomm condition and condition for T180-TRTYP.
regards,
Umar Abdullah
You can check here:
https://labs.aweber.com/docs/code_samples/subs/create
The script to add a new subscriber to the list via api requires those two pieces info...only I cannot figure out for the life of me what those two variables are!! I've beaten through every little aspect of my Aweber Subscriber Account, AND my Aweber Labs account...and I can't find any reference to either of those variables anywhere. I've submitted some tickets to them, and haven't gotten any response yet.
Does anyone have any ideas here? I've tried my account names, my list names, to no avail!
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Okay, I've got it! You can get the values of both of these variables by dumping some other variables in the aweber api after making certain api calls.
get the account id first:
$account = $aweber->getAccount($accessKey, $accessSecret);
then vardump or print_r $account.
next we get the list id:
$account = $aweber->getAccount($accessKey, $accessSecret);
$list_url = 'https://api.aweber.com/1.0/accounts/<id>/lists';
$lists = $account->loadFromUrl($list_url);
then vardump or print_r $lists.
And you are all set! I'm so happy I figured this out, it freakin took long enough. Hopefully this saves some one a bit of time.
I too have agonized over finding the $list_ID, so went to deactivate the list, and create a new one, and "discovered" that if you hover over the Deactivate button, you get a url you can copy, and this gives both %account and %list Ids
https://www.aweber.com/users/lists/deactivate/$accountID/$lisID
like this....
https://www.aweber.com/users/lists/deactivate/123456/123456
Hopefully this will help make someone as it is a super easy solution
The proper answer is Anne Allen's one, but...
Check the return of the /accounts endpoint. It should return the same account id as you detected in the link, but I had cases they were different (strange, isn't it?). Use the account id returned by the /accounts endpoint and other endpoints to retrieve lists, subscribers, etc. will start to work. It's like if some accounts have two ids, one partially works and the other fully works.
Let me tell you how to get $list_id value... login into your AWeber account and then create a new list copy only integer value from list's name.
At first, login.
1) click Reports>Settings. Your account ID will be displayed in the box,example: ?id=XXXXX
2) click List Options>List Settings. There you will see the list ID under the name.
p.s. To add subscriber, you can use this - Automatically add into aweber list
I have some questions about 4sq's API.
Chceckin object obtained by checkins/add endpoint's response sometimes has mayorship field and at other times not.
And mayorship's checkins count field seems not reliable (often appears count 0, but actual count is 2).
Is it so?
thanks.
The notification only contains mayor information if the user is somewhat close to being able to claim the mayorship.
As for incorrect checkin counts, you'll need to provide an example response for us to be able to debug.
In Logging Application Block in Logger.Write it takes event id as one of the parameter which is integer.So how to decide what should be passed as event id?
btw, do you really need to use the eventId? I think you can just pass the string you want to log:-
Logger.Write("SomeMessage");
EDIT :- I meant there should be another overload which takes just the string you want to write.
EDIT :- From here :-
EventId - a value you can use to
further categorise Log Entries
(defaults to 0 for a LogEntry and to 1
for a LogEntry implicitly created by
Logger.Write);
What we do is gather the different "stories" that you want to report on and then assign a sequence of event IDs to each of those stories. So in short, come up with a system that works for you and document it for future reference.