I am testing out the Alexa Skills Kit for Nodejs currently.
Under Skill State Management, there are NewSession and Unhandled events.
However, I am going through the documentation and I cannot find these events or Intents anywhere. Are these custom events or obsolete ones?
Unhandled: this intent is called when an intent is invoked which is not handled by your handlers.
NewSession: this intent is called when a new session is created. This happens for example when the skill gets launched.
These events are described (as far as I can see) in the nodejs skills kit: https://github.com/alexa/alexa-skills-kit-sdk-for-nodejs#skill-state-management
Related
Before I get to my question, let me sketch out a sample set of microservices to illustrate my dilemma.
Scenario outline
Suppose I have 4 microservices:
An activation service where features supplied to our customers are (de)activated. A registration service where members can be added and changed. A secured key service that is able to generate secure keys (in a multi step process) for members to be used when communicating with them with the outside world. And a communication service that is used to communicate about our members with external vendors.
The secured key service may however only request secured keys if this is a feature that is activated. Additionally, the communication service may only communicate about members that have a secured key AND if the communication feature itself is activated.
Because they are microservices, each of the services has it's own datastore and is completely self sufficient. That is, any data that is required from the other microservices is duplicated locally and kept in sync by means of asynchronous messages from the other microservices.
The dilemma
I'm actually facing two main dilemma's. The first is (pretty obviously) data synchronization. When there are multiple data stores that need to be kept in sync you have to account for messages getting lost or processed out of order. But there are plenty of out of the box solutions for this and when all fails you could even fall back to some kind of ETL process to keep things in sync.
The main issue I'm facing however is the actions that need to be performed. In the above example the secured key service must perform an action when it either
Receives a message from the registration service for a new member when it already knows that the secured keys feature is active in the activation service
Receives a message from the activation service that the secured keys feature is now active when it already knows about members from the registration service
In both cases this means that a message from the external system must lead to both an update in the local copy of the data as well as some logic that needs to be processed.
The question
Now to the actual question :)
What is the recommended way to cope with either bugs or new insights when it comes to handling those messages? Suppose there is a bug in the message handler from the activation service. The handler does update the internal data structure, but it fails to detect that there are already registered members and thus never starts the secure key generation process. Alternatively it could be that there's no bug, but we decide that there is something else we want the handler to do.
The system will have no reason to resubmit or reprocess messages (as the message didn't fail), but there's no real way for us to re-trigger the behavior that's behind the message.
I hope it's clear what I'm asking (and I do apologize if it should be posted on any of the other 170 Stack... sites, I only really know of StackOverflow)
I don't know what is the recommended way, I know how this is done in DDD and maybe this can help you as DDD and microservices are friends.
What you have is a long-running/multi-step process that involves information from multiple microservices. In DDD this can be implemented using a Saga/Process manager. The Saga maintains a local state by subscribing to events from both the registration service and the activation service. As the events come, the Saga check to see if it has all the information it needs to generate secure keys by submitting a CreateSecureKey command. The events may come in any order and even can be duplicated but this is not a problem as the Saga can compensate for this.
In case of bugs or new features, you could create special scripts or other processes that search for a particular situation and handle it by submitting specific compensating commands, without reprocessing all the past events.
In case of new features you may even have to process old events that now are interesting for your business process. You do this in the same way, by querying the events source for the newly interesting old events and send them to the newly updated Saga. After that import process, you subscribe the Saga to these newly interesting events and the Saga continues to function as usual.
I see that in the Watson Conversation tooling, we can see the usage activity broken down by Conversation intents. Is there a way to access this intent usage data via the Conversation API?
The Watson Conversation service has an API to access and modify the workspace, its components and to obtain the logs. The REST function to retrieve (list) the logs has parameters to pass in some filters.
I wrote a Python-based tool a while ago that exploits most of the API and demonstrates its usage. It supports log retrieval. Note that the duration for which logs are available depends on the usage plan.
You need to access the call for the conversation message and get the intent with the return, something like: response.intents.intent
Like #data_henrik said, the conversation tool can use the getLogs method for access all return, intents, entities, context variables, input from the user and your bot, etc.
See the Official reference here.
We're developing an agenda on our platform. We implemented a feature to sync with Google Agenda which works correctly except that it only works with public calendar and not when it's private.
We implement everything as Google provides and use AuthO2 protocol.
We are migrating to https and we hope that it will solve our issue.
Do you have any idea on the reason it's blocked when agenda is private?
You can implement synchronization by sending HTTP request:
GET https://www.googleapis.com/calendar/v3/calendars/calendarId/events
and adding path parameters and optional query parameters as shown in Events: list.
In addition to that, referring to Synchronize Resources Efficiently, you can keep data for all calendar collections in sync while saving bandwidth by using the "incremental synchronization".
As highlighted in the documentation:
A sync token is a piece of data exchanged between the server and the client, and has a critical role in the synchronization process.
As you may have noticed, sync token takes a major part in both stages in incremental synchronization. Make sure to store this syncToken for the next sync request. As discussed:
Initial full sync is performed once at the very beginning in order to fully synchronize the client’s state with the server’s state. The client will obtain a sync token that it needs to persist.
Incremental sync is performed repeatedly and updates the client with all the changes that happened ever since the previous sync. Each time, the client provides the previous sync token it obtained from the server and stores the new sync token from the response.
More information and examples on how to synchronize efficiently can be found in the given documentations.
The project I am working on is moving from an n-tier to a SOA architecture so I have been reading up on good SOA practices. I'm struggling to understand the dynamic between avoiding RPC style services in favor of event driven services, and the requirement of User Interfaces to retrieve data and do it speedily.
So for instance, ideally a SOA architecture would be composed of repeatable business process wherein you could simply publish a message onto an ESB which would handle finding the services that handle that message. So rather than executing a procedure called "Setup New User" which set out to do all the tasks related to new user setup, you would publish a message into the ESB that just contained the new user's details and had the appropriate document type "New User" and then the ESB would find services that handled that event that would then do whatever domain specific new user provisioning was required.
However, sometimes you just need data. Maybe you have a page that shows some list of user associated data. You can't just fire off a message into the ESB because you need data back and you need it now. Also, you aren't really triggering any business processes; you're just retrieving data from previously invoked business processes (the processes that caused the user to be associated with the data for instance). So to give a concrete example, maybe I just want to see the list of 10 Netflix movies a user has watched recently.
How do you reconcile these disparate types of services in a single SOA system?
In an ESB, where event-driven approach is followed, you have all kinds of listeners, that detect events and act accordingly. These listeners may wait for the appearance of direct messages via some protocol at certain endpoint for example. No matter what the trigger is - a purely business event that starts a business process or a technical call that just needs to retrieve some data, it is still an event that is handled by the ESB. So you are not technically breaking the event-driven approach - it is enforced by your ESB solution. Moreover keep in mind SOA doesn't impose such limitation - you do not have to implement everything in event driven manner.
In your case (provided, you don't have a dedicated BPM solution in place), I'd identify and implement two kinds of services on two purely conceptual layers in the ESB:
Technical services (the event is an incoming direct message for retrieval/modification of data), that can be either called directly by another system (via the ESB) or called by other process services.
Process services on the top (business) layer that are being triggered in a event-driven way (using topic queue for example, where process services listen for their triggering event)
However, this may not be the most optimal approach. I've been discussing business processes in a dedicated business process layer versus process services in the ESB in this topic. Feel free to check it out, because it is kind of related with your question.
I'm making a web application which should be able to monitor calls on my Asterisk server. I can connect to ARI with Javascript WebSocket on URL ws://(host):8088/ari/events?app=dialer and it works. The problem is that I only get events from calls that are made over ARI. Calls made from other clients like Zoiper are not registered. On the other hand, Asterisk has AJAM which uses long polling on http://(host):8088/rawman?action=waitevent and it registers calls from all the clients, (ARI, Zoiper and others) but there's only information who is calling (caller), not whom (callee).
So, my question is, how can I get real time call events that show who is calling who, from all the clients, (preferably) with WebSockets. Thanks.
ARI uses a subscription based model for events. Quoting from the documentation on the wiki:
Resources in Asterisk do not, by default, send events about themselves to a connected ARI application. In order to get events about resources, one of three things must occur:
The resource must be a channel that entered into a Stasis dialplan application. A subscription is implicitly created in this case. The
subscription is implicitly destroyed when the channel leaves the
Stasis dialplan application.
While a channel is in a Stasis dialplan application, the channel may interact with other resources - such as a bridge. While channels
interact with the resource, a subscription is made to that resource.
When no more channels in a Stasis dialplan application are interacting
with the resource, the implicit subscription is destroyed.
At any time, an ARI application may make a subscription to a resource in Asterisk through application operations. While that
resource exists, the ARI application owns the subscription.
So, the reason you get events about a channel over your ARI WebSocket is because it went into the Stasis dialplan application. That isn't, however, the only way to get events.
If you're interested in events from other event sources, you can subscribe to those resources using the applications resource. For example, if I wanted to receive all events that were in relation to PJSIP endpoint "Alice", I would subscribe using the following:
POST https://localhost:8080/ari/applications/my_app/subscription?eventSource=endpoint:PJSIP%2FAlice
Note that subscriptions to endpoints implicitly subscribe you to all channels that are created for that endpoint. If you want to subscribe to all endpoints of a particular technology, you can also subscribe to the resource itself:
POST https://localhost:8080/ari/applications/my_app/subscription?eventSource=endpoint:PJSIP
ws://(host):8088/ari/events?app=dialer&subscibeAll=true
Adding SubscribeAll=true make what you want =)
May be help someone:
Subscribe to all events on channels, bridge and endpoints
POST http://localhost:8088/ari/applications/appName/subscription?api_key=user:password&eventSource=channel:,bridge:,endpoint:
Unsubscribe
DELETE http://localhost:8088/ari/applications/appName/subscription?api_key=user:password&eventSource=channel:__AST_CHANNEL_ALL_TOPIC,bridge:__AST_BRIDGE_ALL_TOPIC,endpoint:__AST_ENDPOINT_ALL_TOPIC
For more clarity regarding what Matt Jordan has already provided, here's an example of doing what he suggests with ari-py:
import ari
import logging
logging.basicConfig(level=logging.ERROR)
client = ari.connect('http://localhost:8088', 'username', 'password')
postRequest=client.applications.subscribe(applicationName=["NameOfAppThatWillReapThisEvent-ThisAppShouldBeRunning"], eventSource="endpoint:PJSIP/alice")
print postRequest