src="" integrity="sha384-2t/t1c09RW9mc610ML5bA5JapmJKFogKytayzlqrzrp3ks0qqR4LleX1T9Nl05V+" crossorigin="anonymous"

Avaya TV

Advanced Breeze Techniques Video-Part 1

This video explains how to use the Error Boundary Task within an Engagement Designer workflow.

>> Hi, and welcome to Advanced Avaya Breeze Concepts. My name is Andrew Prokop, and I work at Aerosystems Integration as a Communications Consultant and Technology Evangelist. In today's video, I want to discuss how to handle error conditions in a Breeze workflow. There are plenty of opportunities for things to go wrong when you write and execute applications.

In addition to stupid programmer tricks, database searches might fail and web services can reject RESTful invocations. Thankfully, Breeze provides developers with a way of catching errors and taking alternative paths when they occur. Let's begin by returning to the snap that I presented in part five of my introduction to Avaya Breeze.

You may recall that I used a cloud service to retrieve and speak weather information. There are a number of things that can go wrong here, but I'm going to choose the easiest way to force an error. I'm going to attempt to invoke a nonexistent service. To do that I will corrupt the URL, invoked by the Call REST Service task, by adding an X after the .org.

So, allow me to save this work flow, and then we'll deploy the work flow. That's before. I will assign it to service profile of pro cap. And service has now been deployed. It's now time to test my weather application. Use one-X Communicator to call the snapping.
>> Welcome to the fabulous borrows systems integration weather application.

Please enter your five digit zip code. [SOUND] Notice how nothing has happened. So, let's actually take a look at this snapping. If I click on with that within console, I see that the snapping has died. And I'll see that I have an error, unknown host. Which is exactly what we thought we would get because I gave it a bad URL.

Okay, let's return to the workflow and add some code to catch and process the error. To do that, you can open up the events cabinet and I'm going to choose the Error Boundary Event. I can use the Error Boundary Event to catch the error and take some alternate path.

So, my alternate path will be, I'm going to, let's say that I will play cool announcement. That says I have encountered an error. So, bring that up. Afterwards we'll just end this hub, now actually let's do this. Let me delete that and let me drop the call make it a little more interesting.

We'll drop the call. Then we will end the flow, so let's connect these together. And play announcement. We're going to have to say something. So, let's say [INAUDIBLE] error. If you remember, from earlier lessons, that we need to map over the universal call ID, so that we know what call- To play this announcement on.

[INAUDIBLE] call ID. And bring that up here. Map that to universal call ID. We announce that, save that. Okay, then you do the same thing here for the drop call. So, start schema again. Start schema is created because this is a call intercept application. Here's the universal call ID, save that.

Hit OK. At this point I have an error, catching an error, play announcement dropping a call. I need to attach this error boundary event to the place the error occurs. And this is quite interesting, so I actually sort of drag it up here and I will drop it on the Call REST Service.

And I've now attached the error boundary of that to Call Rest service, so that when an error occurs in this task, it will take this path. Okay, it's time to save, and redeploy the snapping. Save it We'll do redeploy. Something I haven't mentioned in the past is, when I do a redeploy, it'll actually do a silent validate under the covers.

So, it's validating my workflow, looking for errors. Found none. Again assign it to the workflow. Hit okay. At this point my new improved snapping has been deployed. It's now time to test the new and improved snapping. Bring up my one-X Communicator again.
>> Welcome to the fabulous borrows systems integration weather application.

Please enter your five digit zip code.
>> [SOUND]
>> An error has occurred, dropping call.
>> Okay, well let's go back to the admin console. Click instances, we'll do a refresh. Notice how the error occurred. Now, notice how we have the new path. So, we follow the green circles.

So, the error was cut, was sent to the play announcement, and then the call was dropped. There are many places where you want to catch and process errors. If you're an old Java programmer like me, think of it as exception handling. In normal conditions, the tasks and workflows act as they should.

But if something goes wrong the error task allows a workflow to recover. There are other boundary conditions that I may want to explore in future videos. However, given what you learned today you are fully equipped to figured them out on your own. They are all very similar to the error condition tasks.

With that I will close down this first video of advanced Avaya Breeze concepts. Be sure to subscribe to the Arrow Systems Integration, YouTube channel for future installments. Bye for now.
Error: There was a problem processing your request.