Writing Avaya Breeze Snap-Ins Using Engagement Designer Video-Part 1
Welcome to the first in a series of videos that explore writing Breeze applications, or Snap-Ins as they are more properly known. Each video will build upon the previous to take you from the fundamentals of Breeze to its most powerful tools for developing scalable and highly flexible communications solutions.
>> Hi, welcome to the first in a series of videos describing, as well as demonstrating, the Avaya Breeze platform. My name is Andrew Prokop, and I work at Arrow Systems Integration as a communications consultant and all around smart guy. You may know me for many written articles for No Jitter.
But I decided to do something a little different this time around. If a picture tells a thousand words, I hope these videos become my virtual novel. The name Breeze may be relatively new, but the technology's been around for a number of years. It began as Collaboration Environment, before being renamed Engagement Development Platform, or EDP for short.
At its core, Breeze is a platform to develop sophisticated telephony applications, but it's so much more than that. Built on IBM WebSphere, Breeze applications, or snap-ins, as Avaya calls them, can do just about anything you want them to do. In fact, I have written Breeze applications that send emails and text messages, query databases, make recordings, send and receive RESTful web services calls, and implement speech recognition.
Avaya provides two methodologies to develop Breeze snap-ins. First, there is a Java software development kit that enables experienced Java programmers to write straight to the Breeze APIs. This is how I began working in the collaboration environment several years ago. Second, there is a drag and drop tool that Avaya calls Engagement Designer.
Engagement Designer is in itself a snap-in that invokes the underlying Java APIs. However, Engagement Designer shields the developer from the nitty gritty Java details and essentially allows anyone who can dream up a workflow to become a developer. In addition to Engagement Designer making it very simple for non-programmers to create powerful applications, the time from idea to prototype to production is significantly reduced.
I am not exaggerating when I say Engagement Designer can reduce snap-in development time from days to minutes. Okay, that's enough of an introduction. Let's take a first look at writing Breeze applications. For this video and a number of videos that will follow, I will focus exclusively on Engagement Designer.
Frankly, it's a lot more exciting than looking at hundreds of lines of cryptic Java code. And while there are some things that you can do with the Java toolkit that you cannot do with Engagement Designer, the differences in functionality are few. First, I need to show you how to invoke Engagement Designer and some of its associated tools.
For that, we begin with System Manager. System Manager is Avaya's centralized management platform for all things including Breeze. This is the main screen for System Manager. Note the entry for Engagement Development Platform. The version of System Manager I'm using for this video is one level below the current version, where you would see Breeze instead of EDP.
However, the functionality and work flows are identical. To get to the Breeze tools, we click on Engagement Development Platform. This takes you to a screen that allows you to manipulate all sorts of things about Breeze and Breeze servers. For these videos, I will concentrate on just a few aspects.
After opening Engagement Development Platform, you are placed on the Cluster Administration screen. Think of a cluster as a collection of Breeze servers. I am using UCCLUSTER. Let's scroll over and see what tools have been loaded for this Breeze cluster. Notice Design Console URL. By selecting this, I launch Engagement Designer.
Allow me to explain what you are seeing. On the left side is a collection of cabinets. If we open up the Telephony Communications cabinet, we see all the tasks associated with managing telephone calls. The same is true for other cabinets. For instance, if I open up Media Communications, I see four tasks that can be used to manage media within a snap-in.
Across the top, you'll see a menu of options that are used for snap-in development. We have things like New Workflow, Delete Workflows. I'm gonna talk about a number of these things, Validate Workflow, Import Workflow from a file, Deploy a Workflow. And a number of other options that will be useful once we get into snap-in development.
The big panel on the right is where you create your snap-in. By default, all snap-ins have a start event, variables, and properties. I will address variables and properties in subsequent videos. Start is where a snap-in's workflow begins. There are many ways to trigger start, and over time, I will explore most of them.
For now though, we'll look at things simplistically, and manually start our snap-ins. Are you ready to begin? Great, let's get started on a very simple snap-in that makes a call, place a message, and then drops the call. For this, we need to open up Telephony Communications and find Make Call.
And it's right there. This, of course, is the task used to launch a new call. We then need something to play the prompt. The Play Announcement task is found under Media Communications. At this point, we want to drop the call and now, we want to end this workflow, so we open up the Events cabinet and find End.
Okay, let's connect these tests together for a linear workflow. I go to Start. I allow the blue arrow to appear. Click on it and drag over the connection line until the green box appears around MakeCall and then I let go. I'll do the same for MakeCall to PlayAnnouncement.
PlayAnnouncement to DropCall and then, DropCall to End. Now, are we done? Well, not quite. We haven't said who we want to call or what we want to say. For that, we need to open up the individual tasks and set their properties. If I go over to MakeCall, I can either right-mouse-click or I can double-click.
I will right-mouse-click and we see Properties. If I open up Properties, I need to set the Calling party. For my example, I'm going to use 2301. The Called party is 22304. I'm going to send an arbitrary Call ID and I can say, OK. Input and output mapping allow you to access data defined outside the task and make data produced within the task available to other tasks.
By opening Input Mapping, you will see the variables that were available as task properties. In future videos, I will explore how these can be mapped. But for now, we will work with the hardcoded values I just set for Calling party, Called party, and Caller ID. Opening up Output Mapping displays the values produced when MakeCall runs.
Specifically, we see Universal Call ID or UCID and status. We need UCID for future operations and need to make it available to other tasks. There are different ways to do this, but the easiest is to simply make a public copy of this data. This is accomplished by clicking on the plus sign, the green plus sign.
Notice how we have now created something called MakeCall1_Output_1. This data is now publicly available to other tasks. Let's save this data and move on. It's now time to work on the prompt that the called party hears, and save that. So, let's double-click PlayAnnouncement. And we see the local properties of the PlayAnnouncement task.
For now, I will ignore everything except Media URI / Text. Here, I will simply type the words I want the called party to hear. So let's say Hi from Breeze. Isn't this really cool? Let's open up Input Mapping. First, I see the task properties. But I also see UCID.
This is the call I want to play the prompt on. In this simple workflow there's only one call, but imagine a workflow that deals with many calls. UCID allows the task to keep them separate and to process each of the calls separately. So where do I find UCID?
Why, it's from the previous MakeCall task. So if I open up MakeCall1_Output_1. I can map the UCID from the call that we just created to the UCID needed by the prompt. Okay, let's Save this. There is no output mapping that I need to worry about from Play Prompt, so I will just ignore that and let's close this thing out.
Opening up DropCall doesn't show me much. However, if I open up Input Mapping, then we see the same UCID as required for DropCall. Which makes sense, we need to know which call we are dropping. So I will map over the UCID from the MakeCall, and then add that to the DropCall, and we'll Save this.
We are now ready to run the task. To ensure that I didn't make any mistakes, I will go up to the menu bar and I will choose Validate Workflow. Validate Workflow will go through my workflow and ensure or tell me if I have any syntax errors. So it won't tell me if I have logic errors like programming errors, like I'm doing something I shouldn't do in terms of the logic of the workflow, but it will find any syntax errors.
Have I mapped all the things that needed to be mapped? Have I set all the variables that absolutely have to be set? Well, in my case, I did fine. Zero errors, zero warnings, but let's have a little fun. Let's go into DropCall. Let's go back into Input Mapping and I'm going to remove the UCID mapping I just made.
Let's Save that and there is no mapping. Do you want to save and I say, Yes. I'm living dangerously here. Let's go back up to Validate the Workflow. And it's going to tell me hey, you didn't map UCID. I need UCID map. So let's close that out, go back into Input Mapping.
Let's remap that and we'll save it. And then we'll hit OK. I will re-validate. Okay, perfect. We're back to where we were before and we are ready to run. Now that the snap-in workflow is complete, I need to save and deploy it. So I go over here to Save.
It wants a name. I'm going to call this my MakecallDemo. That seems good enough. MakecallDemo. Although I will correct my Call, I'm going to assign it to a directory that I currently use and I will say Save. Oop, it looks like I've already made that, I've already used that one.
So we'll call this one MakeCallDemo1. Now, I need to deploy it. So I come back over here. I say Deploy Workflow. Here's MakeCallDemo1. This is Version 1. I click OK. Engagement Designer will come back and tell me that the workflow has been deployed. To test the snap-in, I need to return to System Manager and run another tool on my Breeze cluster.
So I'll go back to the Breeze cluster, and this time we select Admin Console URL. Let's wait for it to start. The Admin Console URL has three main sections, Workflows, Instances, and Event Catalog. And we'll talk about Event Catalog in another video. Today, we'll talk about Workflow, and I'll show you some things about Instances.
Looking down at Workflow, I see my newly deployed snap-in, MakeCallDemo1. I will select it, and then I will click on Create Instance. This invokes the snap-in at the Start task. I get a little warning here. This is something I wanna talk about later, because we're not doing events right now.
And I'll say OK. What happens [SOUND] is the Instance is created. And look at this. I have running on my PC here, [SOUND] one-X Communicator. And I'm logged into 2304, so let's answer that.
>> Hi from Breeze. Isn't this really cool?
>> We saw the MakeCall. We heard the prompt and we saw the call dropped.
[LAUGH] That was pretty neat, wasn't it? There's one more thing I want you to see in Admin Console. Let me go back. I'm going to restart my snap-in, so I'll do my Create Instance. Get the warning that I said we can ignore for this point. [SOUND] I have my ringing call.
Now, I'm gonna click on Instances. Make sure I do a refresh here. And I see MakeCallDemo. [SOUND] If I click on this, we will see the task actually as it's in progress, so let me come back here. I'm going to answer the call, notice we're sitting at the MakeCall.
[SOUND] I will answer it.
>> Hi from Breeze. Isn't this really cool?
>> It's moved over to the PlayAnnouncement. Then it moves over to the DropCall and then it goes to End. So when we saw the kind of the yellow orange, that is a task in process. When we see the green, that is a task that has completed.
So this is extremely powerful, the ability to dynamically watch workflows in real-time or historically. I can go back and close this and I can look at the one I ran earlier, so look at them historically as well, is extremely powerful. It's actually one of the coolest things about Engagement Designer.
And I have personally used this capability to fix quite a few bugs in my snap-in's logic. And so, we talked about the validation to fix the syntax, well, this is how you can start to fix your logic errors. That's not fixing them for you, but it's showing you what is going on, what is happening.
I can actually open up various of these tasks and I see what it was doing at the time of execution. And this could be extremely important when you think you are doing something and you really aren't doing what you thought you were doing. Because the task says no, that's not the data that I see, this is the data that I see.
This was meant to be an introduction to Breeze and I hope I accomplished that. As you saw, there is a lot to this product and I have only scratched the surface. Future installments of this video series will explore variables, properties, and quite a few of the many tasks an engagement designer provides.
If you think this was exciting, just wait until you see what I can do with RESTful web services. Trust me, you will be amazed. With that, I'm going to close this out, thank you for tuning in. Please subscribe to Arrow Systems Integration YouTube channel for future installments. Bye for now.