Avaya TV

An Introduction to Avaya Breeze Workflow Properties Video-Part 2

The second in a series of videos that explore Avaya’s Breeze development platform. In this installment, you are introduced to Snap-In Properties and Attributes.

>> Hi, welcome to part two of my Introduction to Avaya Breeze. My name is Andrew Prokop and today I'm going to expand on the snap in a creator in part one, and find a few ways to make it a little more flexible. Specifically, I'm going to talk about Snap-in properties and attributes.

The Snap-in I built in part one was pretty straight forward, it made a call, played an announcement, and then dropped the call, sync robocall. However, it would be a very limited robocall since we hard-coded the call it number in the announcement into the snapping. It would only be effective if you wanted to call the same person over and over again, saying the exact same thing.

Thankfully, Avaya provides a number of ways to customize realtime instances of snap-ends. Today, I'm going to address one important way. As you will eventually see, it may not be the best way to address this particular snap-end, but the concepts apply to more complicated solutions. Let's begin by taking another look at the make call snap-end.

Begin at the star task before advancing to make call, play announcement, drop call, and ultimately the end event. If I open up mid call, you will see the hard-coded value for called party that I set in part one. Properties are like variables, except they aren't set at runtime within a snapping.

The property that is outside the snapping and is populated before a snap in this in vote. As with tasks, a right mouse click or a double click will open up properties. I haven't added any properties to this snap in, so it comes up empty, but let's click on add a new property and create something called call add party.

It needs a value, so let's set what we had in the make call test, 2304. While I am here, I will create a property for the announcement plate when the call is answered. Let's call it greeting and set the value to hi from breeze, this is the sound of a property.

So to greeting, hi from Breeze. This is the sound of a property. I will now save these values and return to make call. So let me open up make call. Let's delete the value for callout party. Now let's open up input mapping. Notice that properties now show up on the left side, and there are the two properties I just added.

So let me copy over callout party from the properties to the callout party used by this particular task. Let me click save. Notice how the make call properties show that call out party now comes from properties. It also maps call out parties to caller ID. Honestly, I have no idea why this happens.

When we close this out, Want to do something similar for my announcement. So I'm going to delete media URI text, and go over to input mapping, I'm going to back to properties, I'm going to find the greeting that we just created. Now I'm gonna map this over, I will save this.

Now notice also, as with that properties.greeting is what is mapped into the properties of play announcements. So it realizes that the input is coming from somewhere else. Okay, allow me to go to system manager. And then under, engagement development platform, I'm going to open up configuration. And under configuration I will open up attributes.

Attributes are where snap and properties are stored and manipulated. There are many ways to view and manipulate attributes, but for simplicity, I will choose one. By clicking service globals, I can work with attributes and properties for a snap in at a global level. Scrolling down, I will eventually come to MakeCallDemo 1.

I'll open that up, and what do I see? Why, I see the properties that we just created. For fun let me change the greeting to something different. So I'll open up greeting, and now instead of this is the sound of property, this is the sound of attribute. Let's commit that.

Let's return back to cluster administration. Let's open up Admin Console. We'll select MakeCallDemo. We'll create an instance. As with the part one, we're going to ignore this for now. [NOISE] I have my incoming call. Let me answer it. [INAUDIBLE]
>> Now did you hear that? Even though I had hard coded the greeting to say this is the sound of a property with an engagement designer, I manipulated it outside of the snap in.

I hope you are starting to understand the power of properties. Although this snap-in is still quite trivial. The idea of manipulating run time data outside the engagement designer is a very powerful concept. Imagine the kinds of data that you can make accessible to an administrator, URL's, login ID's, timeouts, etcetera, etcetera, etcetera.

Still properties and attributes are fairly static in nature and would be cumbersome to change them often. That's where snap ins integrated with databases come in, but that's a topic for another day. I hope you found this helpful. In future videos, I will discuss additional enhancements that can be made to the Make Calls snap in before branching off into snap ins that intercept incoming calls and those that integrate additional forms of communications into a workflow.

With that, I will close out Part II. Please subscribe to the Arrow Systems Integration YouTube channel for additional videos in this series. Thanks again for tuning in and bye for now.
Error: There was a problem processing your request.