Writing Avaya Breeze Snap-Ins Using Engagement Designer Video-Part Six
This video presents Breeze Events and demonstrates how a Snap-In can be remotely invoked using web services.
>> Hi, and welcome to part six of An Introduction to Avaya Breeze. My name is Andrew Prokop and I work at Aero Systems Integration as a communications consultant and all-around good guy. For this video, I want to spend some time talking about and demonstrating Breeze events. In the first three videos, I skirted around a warning message that appeared when a snap-in instance was created with the admin console.
Today, I want to not only show you how to make that warning go away, but give you a powerful tool to integrate snap-ins with external services. Are you ready to begin? Great, let's get started. So far, I've shown you two different ways to populate data. The easiest way is to hard code the values into a task, for instance, the Make call task requires values for caller and called.
In part one, I simply enter them into the task. In part two, I introduce you to the concept of properties and attributes and showed you how an administrator can set those values with System Manager. While this adds a bit more flexibility, it's far from ideal as snapping attributes are typically locked in.
If you watched part four of this series you saw how to set event family and event type in the start task. The Call Intercepted event family comes within Engagement Designer and is used to launch a snap-in from an incoming call. Avaya provides a few more events that you can apply to snap-ins to allow different invocation conditions.
The Breeze development platform also allows you to create your own events. Not only does this provide you with flexibility as to how a snap-in is invoked, but as you will see later in this video, it opens up a line of communications between the snap-in and a service external to Breeze.
To create an event, go to the Breeze Admin Console and click on the Event Catalog tab. The Create button opens up a window to enter data about your event. However, for efficiency's sake, I will open up an event I previously created and walk you through it. We can open up one that I call Communications Event.
So I built Communications Event to contain enough information to build a basic snap-in for outbound telephony, SMS text, and emails. Family defines the event family. A single event family can contain many event types. No spaces are allowed. Family Display Name is for family documentation purposes. Here, spaces are allowed.
Event Type is the event the snap-in will trigger on. In this case, I've defined something called launch alert. This is the event that will be used to launch a new instance of my snap-in. Event Type Display Name is for documentation purposes again, and also, spaces are allowed. All events require a version number.
I started this event at version 1. Every event needs a JSON formatted schema. First, you give it a name, then you define the schema contents. While it's possible to build the schema by hand, I would much rather use the built-in JSON schema editor. Here I've created a kitchen sink schema that contains enough information to populate Make Call, SMS text, and email tasks.
Notice the placeholders for Caller, Called, SMS Recipient, SMS Sender, Email Recipient, and on and on. While I don't necessarily need all of this information for every communications workflow, it's there if I want it. Okay, well, let's go and use this communications event. I'm gonna close this out. To do so, I'm going to return to the Designer Console.
I'm gonna create a very simple workflow. A start, a Make Call, and an end. So with start, though, let's open it up. Going to set the event family to my communications event. I'm going to set Event Type to my LaunchAlert. Again, I need a version number. I want you to see, though.
Since I used my communications a bit, it becomes my StartSchema. Let's save this. Now let's do our Make Call. I need values for the calling party, the called party. Well, I can go to Input Mapping, to Start Schema, and lo and behold, there's the caller. Here's the called party.
They get filled in up here. Click OK. We will need an end. Let me put this together. As always, I like to validate my workflows. Zero errors, zero warnings. So let us save this one. Save it to my Prokop folder. Call this ComEventText. Now let's deploy the workflow.
And the workflow is deployed. So to launch the workflow, I need to return to my Admin Console, go to Workflows, here's EventTest, click on Create Instance. Woah, would you look at that. So instead of that warning we were getting before, we're asked a number of questions, the questions that were in the event.
So we need a caller. I'll call this 2304. And I'll use on my calling party, 2301. Now, I could fill in message body and subjects and SMS sender, but since my workflow doesn't use those, it's not necessary. They are there, though, for future workflows that wanna use this communications event.
So let's hit OK. [SOUND] And here's my incoming call. I'll answer it and then I'll release it. Using Admin Console is a very static way of launching a snap-in. What we really need is a way to create an instance of a snap-in without having to use a Breeze tool.
Of course, isn't that exactly what I did in Part Four when I launched the snap-in by calling the telephone number associated with its service profile? I didn't have to go to Admin Console and click Create Instance. I can do something similar with the snap-in I just created by sending it the communications event from an outside source.
For my outside source, I'm gonna use Google's Postman application to create and send RESTful web services messages. Postman is a great development tool for creating these messages and playing with Web services. In the real world, these commands would come from cloud services or business applications. I like to launch Postman from withinside of Chrome.
And here's a previously created RESTful request. Near the top is the URL of my Breeze server. So we see https, and then I see an IP address which represents my Breeze server. services/EventingConnector/events for events is used for all RESTful requests to Breeze applications. Under the body, I see family, which is Communications Event.
type, LaunchAlert, version, 1. These are all things that I created to match what I created in Admin Console for this event. In the event body is the JSON that will get sent to the snap-in. In this case, for my make call, I only need two things, a caller and a called.
This was an email snap-in that I would include other things such as subject and email recipient and I would do it in the same way. To launch this event, I simply click on Send. [SOUND] Here's my incoming call. I can answer it and I can release it. So, basically what I did, was I did the Create Instance that I would have done in Admin Console, but I did it from another application.
And I sent the post command to my snap-in, telling it to launch itself and to run. The ability to use web services to evoke snap-ins is extremely powerful and the practical examples are numerous. Imagine watching snap-ins from inventory systems, Internet of Things devices, property management systems, medical sensors, security systems, etc, etc.
Seriously, the sky is the limit as to how you can apply this technology. While today's example was trivial, the toolset that Engagement Designer provides allows for extremely sophisticated applications that go well beyond making simple telephone calls. With that, I will wrap up part six of my Introduction to Avaya Breeze.
Clearly we are moving beyond the easy aspects, but I hope you are able to grasp what I'm presenting and see how you might apply it to your enterprise. Be sure to subscribe to Arrow Systems Integration YouTube channel for more fun and games. Bye for now.