Advanced Breeze Techniques-Part 5
This video describes the many tools that can be used to debug Avaya Breeze Snap-Ins.
>> Hi, and welcome to Part five of Advanced Avaya Breeze. My name is Andrew Prokop and I work at Arrow Systems Integration as a communications consultant and agent for change. In a perfect world, everything works exactly as intended. In the realm of programming, this means that your applications do what they're supposed to do every single time.
However, the real world is far from perfect, and programmers do dumb things, systems fail, and data can be flawed. Today I want to show you several tools that you can use when your Breeze Snap-ins go south and you need to find out why. For the most part, Snap-in debugging tools require that you open up a terminal emulation connection to your Breeze server.
This means you need to fire up PuTTy or TuTTY. Personally, I use TuTTY, but for the purposes of debugging Breeze, PuTTy is just as good. In either case, you must set up the connection to your Breeze server. You need the IP address of your Breeze server. The port is always set to 222 and SSH is used for the emulation protocol.
Once you have the correct values, click Open. I then need to login to my Breeze server. There are several tools that I find useful. To watch all the SIP messages that come in and out of the Breeze server, launch traceCE. And capitalization is important. TraceCE is a Python script modeled after the session manager tool traceSM.
To find the definitive user's guide to traceSM, and subsequently traceCE, refer to my blog article, A Necessary Guide to the Avaya TraceSM Utility. This is accomplished by simply searching for traceSM, my article is always the top entry. For fun, I'm going to call in to my weather application, the one that I demoed in the introductory series.
I believe it was video number five.
>> Welcome to the fabulous Arrows Systems Integration Weather Application.
>> And I'll just hang up here.
>> Please enter-
>> So you notice all the SIP messages that are generated and sent to the Breeze server, actually sent to and from the Breeze server.
If I come over here and I decide that I want to look at one of them, I can simply just find [INAUDIBLE] message. And then I hit Enter, and then the message is displayed. I can walk down the line, I can see any of the various messages that are generated during the transaction.
The next important tool is traceHTTP. You can use traceHTTP to watch the web services commands sent to your Breeze server. You may recall from the sixth video of my introduction to Avaya Breeze, how you can use Google Postman to send RESTful posts to Breeze. traceHTTP allows you to see those messages.
So let me start it up. Capitalization is important. Okay, so it's now running. Let me go over to Postman here, which I started up before. I'm going to select one of the RESTful commands that I already created to send to Breeze. I'll send that. [SOUND] Now, you can here my phone ringing over here.
[SOUND] Okay, if I go back to. My TuTTY command, you can see that I have a post command. If I open it up, you can see the event, and it's a little hard to see in this blue, that was sent to the Breeze server, which caused the Breeze Snap-in to run, which in turn caused my telephone to ring.
Along those same lines, traceBUS is used to watch the commands that fly across the Breeze connector bus. For example, a workflow Snap-in communicates with the SMS text connector across the connector bus, many other things do as well. So let's do this, let's start up traceBUS. I might have to tell it to start right off the bat, capturing.
We'll go back to my Postman and send a command in again, [SOUND] which led to the call. [INAUDIBLE] answer, I'm gonna release it Let's go back to PuTTY and you'll see there are a number of things that were sent. I can open up one of them, honestly, I don't understand what most of this is.
But you can actually see if messages are being sent back and forth, and there's probably something of value. I don't understand it well enough, but it may be of use if you're having problems with the Snap-in. The last debug tool requires me to go to Engagement Designer. Using the Log Message task you can add debug messages into your Snap-ins.
Log Message is found under Notification. Log messages can be designated at seven different levels. The ability for these log messages to appear is determined by the log level set for the cluster. By default, you can see anything with the log level of Info. To see the higher levels, you need to do one of two things.
First, you go into System Manager and under Breeze Configuration, set the logging level. So returning here, I'm in System Manager for my Breeze server, Configuration > Logging. Because I'm dealing with Engagement Designer tasks, I need to set the log level for Engagement Designer. Again by default, everything set to Info will appear in the logs.
If I wanna set it to something higher, then I need to select that higher level. I will tell you though, you will get a warning if I set it to FINE, or FINER, or FINEST, because those messages, or those levels, generate a lot of log messages. And System Manager warns you by setting it to that higher level you can potentially slow the system down.
These log messages are subsequently viewed with a CE tool. There are a number of ways that CE can be run and I will use the most straight forward. By launching ce dlogw EngagementDesigner, you can see all the log messages created by the Log Message task. So again, ce dlogw EngagementDesigner.
Now, again, I am decking the log messages for Engagement Designer. If I were to write Java Snap-ins, then I would use the specific Snap-in name. But that's not the case for Engagement Designer workflows, you always debug Engagement Designer. And you can see there are a number of messages already in there.
So the flow would be, I return back to Engagement Designer. I could set a message, I'm gonna just leave it at Info here. And I can say, I have reached this part of my Snap-in. Are you curious as to what's happening, or I could actually start to add variables and things like that in there.
But at this point I'm just gonna say I've reached this part of the Snap-in. Hit OK, that would complete the Snap-in, execute the Snap-in. And then those messages, the info messages, would appear in the ce dlogw stream. You can also change the logging level within PuTTY by using the command, ce dlogon and then EngagementDesigner.
So let me get out of this, Control C. So ce dlogon, and then EngagementDesigner. Notice how it tells you that I've set the logging level to All, so it is going to log everything. But make sure that you set the logging level back to Info after you have finished.
So this is accomplished with ce dlogoff EngagementDesigner, so ce dlogoff And then notice how it's told me that it set it back to Info. So this is an alternative to going into System Manager and doing it. So I can do it straight from TuTTY, but remember, you turn it on, then run your ce dlogw, and then when you're all finished turn it off.
You don't wanna leave that on forever, because as I said, it could generate far too many messages. There are more ways to debug and trace Snap-ins. But the tools I've showed you are powerful enough to do just about anything you might want to do. With that, I will close out this episode of Advanced Avaya Breeze.
Thank you for watching. Make sure you subscribe to the Arrow Systems Integration YouTube channel for future videos. Bye for now.