Kynetx Flow of Control in CloudStatus

2010-11-08T17:46:00.000-07:00

The development of solutions within an event based language like Kynetx requires you to remap your architecture skills. It's more common for us to apply object oriented or functional methodology, but not so common to apply an event architecture. To that end I wanted to share with you the architecture of the CloudStatus Kynetx application.

First a brief overview so that you have some context. The CloudStatus Kynetx application provides the status of 26 public APIs. If there are currently any performance issues or service disruptions one quick phone call or text message to (801) 988-9093 will provide the status. When you first call CloudStatus a summary of the services with issues is given, after a short greeting. Then you are presented with a menu of choices. After selecting one of the menu options, and hearing the results, the menu of choices are repeated. Now let's see what that looks like when implemented with Kynetx.

Below is a skeleton of the CloudStatus application. So that we can focus on the flow of control in the application some of the details have been abbreviated or removed. The full source code for CloudStatus Kynetx application is available at GitHub.

The entry point into the application is an incoming call from Twilio, rule #1 twilio inbound_call. After the gretting we raise an explicit event which gives the summary of under performing services. Then another explicit event is raised which takes you to rule #2 explicit givemenu.

Rule #2 is at the top of the multi-select loop and is the center piece of the applications flow of control. One of the main features to note is the parameter passed into gather_start(). It is the event name we have choosen, and it is used in many of the rules which follow. In addition you will notice that we have specified that only one digit will be accepted. So when the caller pressing a single digit we will be off and running.

When the caller presses 1, 2, 3 or 0 rule #3, #4, #5 or #6 is fired respectively. Otherwise, Rule #8 is fired. This is the multi-select pattern! So if the caller presses number 1, rule #3 will fire because it matches the event name statuschoice with the qualifier Digits "1". Recall from above that we choose the event name statuschoice in the gather_start() action. The next rule to fire will be #7 which matches event name statuschoice and any one of the digits 1, 2 or 3. This rule provides the looping which takes us back to rule #2 by raising an explicit event. If the caller presses either the number 2 or 3 the pattern is similar.

If on the other hand the caller presses number 0, then Rule #6 fires, which says goodbye and terminates the call. You will note that Rule #7 does not fire when the Digits is 0, so the caller is not taken back to Rule #2 to hear the menu. The application flow drops through to the end, no loop. there are done.

Finally, if the caller presses any other number then Rule #8 fires, telling them of their poor choice and then taking them back to Rule #2 by raising an explicit event.

edoism

Kynetx Flow of Control in CloudStatus