Writing Avaya Breeze Snap-Ins Using Engagement Designer Video-Part Four
The fourth in a series of Avaya Breeze demonstrations. This video demonstrates how Avaya Breeze can be used to manipulate incoming telephone calls.
>> Hi and welcome to part four of an introduction to Avaya Breeze. My name is Andrew Prokop and I work at Arrow Systems Integration as a communication consultant and a technology evangelist. In parts one, two, three of this video series, I explored a simple made call snap-in consisting of a variety of engagement designer test, connected together in order to place a call, play an announcement, collect a digit and make a decision based upon that digit.
The snap-in was launched manually and used fairly static data. Today, I'm moving away from outgoing calls and turning my attention to developing a snap-in invoked by an incoming call. While many of the Breeze constructs are the same as what you saw with the make call snap-in, there are a few significant differences.
A Breeze server is a SIP entity connect to an Avaya session manager. In the previous videos, my snap-in used session manager and communication manager to make and release calls. It also use the Avaya media server to play announcements and collect digits. For the call intercept snap-in, I will continue to use both session manager and the media server.
But instead of telling session manager to create the call, session manager is going to invoke my snap-in when the new call has arrived. Session manager in Breeze allow an administrator to configure which calls are of importance to a snap-in. For example, it's possible to configure a snap-in to only run when someone calls my personal extension.
It's also possible to tell Breeze to launch a snap-in when anything within a range of numbers is called. These numbers can be DIDs or toll free numbers. I can also use session manager in Breeze to invoke a snap-in when an endpoint makes a call to the outside world.
For instance, I may wanna snap-in that blocks users from calling certain numbers at particular times of day. This configuration of numbers occurs in two places. First, session manager will determine which numbers require Breeze involvement, and Breeze will determine which snap-ins run when those numbers are called or called from.
Let's begin with session manager. You are looking at the implicit users portion of session manager configuration. Think of implicit users as telephone number patterns. For this video, I want you to pay attention to 2304. I configured session manager to send all calls that originate from 2304 or terminate to 2304 to the server called CE1.
CE1 is my Breeze cluster. Moving to engagement development platform, there's a similar entry for implicit users. This configuration allows me to associate the numbers that Session Manager sends to Breeze to Service Profiles. In this case, 2304 is being sent to the service profile I call Prokop. Inside the Service Profiles, are references to snap-ins that will be invoked for the numbers configured against it.
This is where I'm going to configure the call intercept snap-in I am about to write. It's now time to build the snap-in. As always, a snap-in begins with a start event. Unlike my previous make call snap-in though, I'm going to open this one up and set a few values.
In order for my snap-in to launch on an incoming call, I must set the Event family to Call intercepted. Since I'm interested in incoming calls, I set the Event type to CALL_INTERCEPT_TO_CALL a party. Lastly, I need a version number. I choose the default of 1.0. Let's keep this simple and play an announcement before allowing the call to ring through.
For this I need one announcement. Let's keep it fairly simple. Thank you for calling Arrow Systems Integration. As always, I need to map over a universal call ID. But this is interesting, this is different than what we had before. Before, we had the universal call ID coming from the make call, but now we have the universal call ID coming from the start schema.
This is a call intercept, snap-in, and it will come with this start schema that contains a lot of information about the call including universal call ID. So, I can map that over, Save it, OK. Next, I want the call to just ring through to the caller party. So, let's open up Telephony Communication, bring it over, Allow Call, connect these together, open a Property.
The only thing I need to do here, is map over CID, Save this. Then lastly, I needed an end for that. I think we are ready to go but I really ought to validate the workflow. Zero errors, zero warnings, everything looks good. So now, let's save this snap-in.
I can put it in my Prokop folder. Let's call this incoming task, Save. And now, let's deploy the workflow. So, we've done this before in other videos, with one difference. I'm going to assign it to Service Profile, I'm going to use service profile, Prokop. Click OK. And Breeze tells us that this snap-in has been successfully deployed.
It's now time to test. Unlike my make call snap-in, I'm not going to use admin console to create an instance of a snap-in. Instead, I will call the telephone number associated with the snap-in. I will do that with my 1x client. 2304.
>> Thank you for calling Arrow Systems Integration.
>> Begins the call. [SOUND] Did you hear that? The caller heard the announcement before the call rang through to 2304. Even though I did not launch the snap-in with admin console, I can still use it to monitor snap-in. This is a record of the snap-in I just exercised.
I can do the same thing with the snap-in in progress. Well, there you have it, a simple yet fully functional call intercept snap-in. Aren't you impressed by how quickly I was able to put that together? Seriously, that same thing would take me hours with a traditional API such as T Zapping.
In future videos, I will build upon this work by adding other forms of communications as well as web services, with that I will close out this fourth video. Please subscribe to the Arrow Systems Integration YouTube channel for additional installments. Bye for now.