Writing Your First Avaya Aura Collaboration Environment App

This is my fourth blog article about the Avaya Aura Collaboration Environment. My previous articles were fairly high level in nature and explained what you can do with Collaboration Environment, but didn’t go into a lot of detail about how to make the magic work. In this article, I am going to take you much deeper and introduce you to the process of developing a Collaboration Environment application.

While knowing how to write Java code is certainly helpful in understanding the nitty-gritty aspects of creating Collaboration Environment applications, I will do my best to hold your hand through those parts. Don’t get scared away just yet.

Are you ready? Great, let’s get started.


A word to the wise–you will gain a deeper understanding of this material if you first read through these related articles:

The Avaya Collaboration Environment

Avaya Call Intercept Services

An Introduction to Avaya Collaboration Environment 3.0


First, Collaboration Environment applications are written in Java. Period. If you are a C# programmer, you need to find yourself a good book on Java and get busy learning it. Of course, since Java is the greatest language ever written, this requirement should not be a problem for real programmers.

That last comment was meant to be a joke…mostly.

The development environment for Collaboration Environment applications consists of Eclipse For Java EE Developers and Maven. Both are available as free downloads and are fairly simple to install. Grab the latest tested releases and you will be fine.

Note that Avaya SDK requires that you set a number of Environment Variables for Eclipse and Maven. Please refer to the installation manuals or videos for details on which ones need to be created.

Eclipse is the IDE (Integrated Development Environment) in which you will write all your Java code. For nearly every Java programmer that I know, this should not come as a great surprise. Eclipse has been around for a long time and is a very popular development tool. I started using it over ten years ago and it’s still my IDE of choice.

Maven is used to package and build your Collaboration Environment application. I will admit that this is my first experience with Maven, but I found it easy enough to figure out and far less complicated than old-fashioned Make files. Better yet, there is a plug-in for Eclipse that hides nearly all the Maven plumbing and allows you to concentrate on writing code. Maven does the heavy lifting of building the deliverable that gets loaded onto a Collaboration Environment server.

Of course, since you are writing Java code, you must install a Java Software Development Kit (SDK). I use the glassfish4 release, but that’s certainly not a requirement.

You also need to obtain the Collaboration Environment SDK. This can be downloaded from the Avaya DevConnect site. You will also find a number of excellent videos up there that walk you through the installation and configuration process. I found them to be invaluable to my success.

Avaya created a Maven archetype that makes it extremely easy to write your applications. With just a few key strokes and mouse clicks, I was able to create the skeleton of a Call Intercept application that looks something like this.

public class MyCallListener extends CallListenerAbstract {

private static Logger logger = Logger.getLogger(MyCallListener.class);

public MyCallListener()

{

}

public final void callIntercepted(final Call call)

{

logger.fine(“Entered callIntercepted.”);

call.allow();

}

}

If you are not a Java programmer (and I applaud the uninitiated that are still reading this article), please allow me to explain what you are looking at.

MyCallListener is the container for the code that processes an incoming or outgoing call. This means that it will be executed on every single call that comes in on a trunk or is sent out through a trunk. Of most importance is the method callIntercepted. This is where you put the code that tells Collaboration Environment what to do with a call. By default, callIntercepted allows a call to proceed uninhibited.

Of course, allowing a call to proceed as if nothing happened isn’t all that exciting. To remedy that, you add code to callIntercepted that tells Collaboration Environment to do interesting things with the call.

Those things might include stopping it dead in its tracks (e.g. block list). It might also include sending it to a destination different than the number the caller dialed (e.g. Find-Me-Follow-Me). Even more exciting, you may want to create a conference from this call and invite other people to join in. We can take it even further by having this call launch emails, text messages, video conferences, or anything else your heart might desire (or your business requires).

Once you have latched onto an in-progress call, Collaboration Environment allows you to write an application that manipulates it in a million different ways.

Key to this manipulation is the call object. If you look at the skeleton code you will see the statement call.allow(). This tells Collaboration Environment to send the call on its merry way. The call object allows you to do so much more than that, though.

Here are a few examples:

call.allow() Send the call on to the next hop
call.divert Send the call to a new destination
call.drop Release the call
call.getCalledParty() Get information about the called party
call.isCallingParty() Get information about the calling party
call.initiate() Create a new outgoing call

Using the above, redirecting an incoming call to an operator could be as simple as this:

call.divertTo(“0″);

Adding the text “Important:” to the caller’s name display could be accomplished with the following lines of code:

Participant callingParty = call.getCallingParty();

String newInfo = “Important: ” + callingParty.getDisplayName();
callingParty.setPresentedDisplayName(newInfo);

I could go on and on, but the point is that once you have the call, what occurs next is up to you. You can dip into a database, call out to external service via web services, change the caller’s displayed number, invoke another Collaboration Environment application, or anything else you code into your application. You are only limited by your imagination.

It’s important to know that even though the application is processing a SIP call, there is no need for the programmer to know the first thing about SIP. The SIP URI, headers, header parameters, and message body are all hidden from the application. That’s not to say that you can’t get to them if you really want to, but for most applications, that’s not required. Telling a call to drop can be accomplished without knowing that this will generate an 6xx response or a BYE message.

Now, I wasn’t quite accurate when I said “every single call that comes in on a trunk or is sent out through a trunk.” Collaboration Environment allows you to define exactly which calls you want your application to process. It does this by assigning endpoints and telephone numbers to an application. For instance, you might want to assign everyone in the sales group to one Collaboration Environment application and everyone in accounts receivable to a different Collaboration Environment application. You might want your Collaboration Environment application to only run on the behalf of your contact center agents. You get to decide all that when you install and configure the application.

In addition to simply manipulating telephone calls, Collaboration Environment has connectors to email, SMS text, and video systems. It also provides a media interface that allows you to play prompts and collect responses.

Writing an application that intercepts an incoming call, plays a message to the caller, collects his or her touch-tone responses, deflects the call to a new destination, and sends a text message back to the caller is straightforward and simple.

Building the Application

Once you’ve figure out what you want your application to do, you must invoke Maven to build and create the deliverable. The deliverable is in the form of an svar (Structural VAR) file that is then loaded onto the Collaboration Environment server. The loading and subsequent configuration is done using the Avaya Aura System Manager.

Once an application is loaded and users have been assigned to it, it’s ready to run. It’s that simple.

One more thing. Make note of the logger variable in the skeleton code. This allows your application to write to a system console at execution time — think System.out.println(). This can be invaluable during the development phase.

That’s All For Now

I was pleasantly surprised to see how easy the entire process was. The longest part was setting up Eclipse, Maven, and the Java SDK, but I would have to do that for any Java development project. Once everything was installed and configured, using the Collaboration Environment SDK is a piece of cake. It’s extremely well documented with an organized and well-structured Javadoc. Additionally, Maven greatly simplifies the application development process. It’s almost as if the code writes itself.

I intend to continue documenting my findings as I dig deeper into the SDK and write more complicated applications. I am just starting to play with the data APIs and I have yet to do anything with the media interface.

So much to explore and so little time…

Related Articles:

A totally new way to approach customers—and a million reasons to do so

Last month, Laurent Philonenko wrote about some of the exciting work being done with the Avaya Breeze™ Platform, noting that many of our 2016 DevConnect Excellence Award winners were making the creation of Avaya Snap-ins a center point of their strategies.

There is perhaps no better proof point for this than the efforts of Engelbart Software GmbH, our 2016 DevConnect Partner of the Year.

DevConnect business development manager Bill Petty recently sat down with Dirk Engelbart, founder and owner of Engelbart Software, as part of our new DevConnect 8-and-Out podcast series, and talked about their experiences with Avaya Breeze. Avaya Breeze represents “a totally new way to approach customers,” according to Dirk.

In the interview, Dirk speaks directly to the opportunities his company is able to pursue through Avaya Breeze, with “millions of use cases” solvable at his fingertips through Avaya Breeze. His examples, including a manufacturing-related solution to enable warehouse workers to reach suppliers by mapping part numbers via SAP integration, clearly demonstrate the power of this platform.

But most impressive is his story of delivering a deal-winning proof-of-concept implementation in less than two days. This isn’t just a mockup, or some fancy slideware that shows what could be done, but rather a demonstrable, tangible example of how it is actually implemented.

We’ve been hearing this speed-to-market feedback from Avaya customers and partners alike, as we’ve been running bootcamps and training programs on Avaya Breeze and related tools like Avaya Engagement Designer. Avaya Breeze simply makes it easy and quick to create solutions that, using more traditional CTI methods, would have taken weeks to months to complete.

So grab a cup of coffee/soda/tea, and have a listen to what Dirk has to say about Avaya Breeze and why Engelbart has shifted all of their development focus towards leveraging Avaya Breeze.

Why Healthcare Providers Need to Deliver Uber-Like Service

I have a confession to make: I’ve never used Uber. Personally, I like to order my taxis the old fashioned way – by calling the local service on my smartphone and paying via credit card. I know, so 2009.

But while seemingly all my friends are now Uber converts, I’ve yet to download the app, because I know it would be used once, or never, and then just sit on my phone. While there are now literally millions of apps available to us, not many of them actually get used. According to data from Nielsen, the average U.S. smartphone user accesses less than 30 apps per month, with 70 percent of total app usage coming from the top 200 apps.

So, which app would get my vote? A recent unfortunate event has made up my mind for me. The event was my son breaking his arm, and the dream app for me would be one that simplified my healthcare journey.

That dream healthcare smartphone app is yet to be created. After we rushed my son to the emergency room, we had to present his insurance card, answer questions about his previous medical history, any allergies to medication, list his emergency contacts and so on, all before he could be admitted to see a physician. By the time he did actually see a doctor, he was in so much pain his screams echoed through the hospital, and I was in tears.

Even worse, when we got to the operating room, the doctor went through the same list of questions. Fast forward another few hours and my son has now been transferred to a hospital room for two days of observation. With each doctor and nurse on duty, most of the questions asked before are asked again.

Now, if I had my dream app available, we would have clicked a single button to instantly talk to emergency responders, who could access my son’s up-to-date medical and healthcare profile. My phone could be geolocated and an ambulance dispatched, with skilled medical staff available who could relay information about my son’s condition to physicians while en route to the hospital. That information might prompt the hospital to make an emergency room available and prep the surgical team for an immediate operation–with the entire procedure being completed in a few hours, and questions restricted to immediate medical issues.

Admittedly, this is expecting a lot from one app: Uber doesn’t especially care about what happens to you once you reach your destination, after all. Is it too much to expect our healthcare providers to focus on providing a seamless experience for their users? The ordeal I suffered with my son recently was made worse because the hospital hadn’t done enough to ensure that I wasn’t frustrated as I progressed through the system, and to link its various points of contact… it lacked an omnichannel customer experience.

This seamless experience in healthcare is what each one of us should expect and healthcare providers should aspire to deliver. We take for granted that when we use Uber, we are going to get a reliable and safe journey that will get us to where we want to be. In the future, healthcare providers that don’t deliver the best possible experience to their customers are going to find themselves left behind by those providers who do.

How Enterprise Virtualization Will Save Your Business in the Era of IoT

Having a backyard full of trees is quite therapeutic during a marathon day of conference calls, but it also comes with a fair share of maintenance: picking up the fallen limbs from the elms, keeping the invasive cedars from choking out other species, and trimming up the oaks to keep them healthy and the fireplace burning through the winter. On those maintenance days, it’s easy to get obsessed with a tree or set of trees that are causing a problem … say, dropping large limbs dangerously close to your daughters’ trampoline. When you’re fixing up your backyard, one problem – one tree – at a time, the solution to the problem at hand often fails to take into account the needs of the larger ecosystem. Unfortunately, for many networking professionals, every day feels like a maintenance day.

We see problems with mobility and service chaining in and across data centers. We see problems with cost and reliability in the WAN. We see problems with scalability and security in the campus. In a nutshell, we see problems. Fortunately, for every problem, there’s a good ol’ fashioned snake oil salesman. We’re inundated with the latest and greatest technologies to solve our woes … even some we didn’t know we had.

The problem is that we’re putting Band-Aids on bullet holes. The bleeding stops, but the real problem is still lurking beneath the surface. It’s not that these fixes are bad. The problem is that they’re being positioned as a cure-all instead of simply tools to address localized side effects of the problem.

The problem is broader. The data center exists to host applications. Those applications exist to enable users. The WAN exists to connect the data center to the campus, which exists for the users. And, of course, the users exist to run the business.

Since the business is the thing we’re looking to keep alive and thriving, those users need to be productive. That means that they need fast, efficient access to the applications that enable their jobs. So, those problems we rattled off earlier are really just symptoms that have emerged as we tried to create enterprise services across silos of control.

If we want to remove the bullet and save the patient, we must recognize the need for end-to-end services and look holistically at Enterprise Virtualization methods that will securely extend services from user to application at scale with on-demand mobility and business continuity. Otherwise, the problem is only going to get worse.

With the Internet of Things (IoT) becoming an ever-increasing reality in the enterprise, the need for services from device to application is going to multiply exponentially. Without Enterprise Virtualization, the burden on IT to deal with every little problem across the islands of campus, WAN and data center will be overwhelming. They simply won’t be able to keep pace, and, as a result, neither will the business. The users will be limited and become frustrated, and productivity will suffer in turn. It’s a bleak picture, but it doesn’t have to be.

Enterprise Virtualization provides a number of advantages that have long been unattainable to the general enterprise. While we’ve managed to achieve “micro-segmentation” down to the virtual machine layer for applications, the very same data is set free at the data center doors and left vulnerable in the less secure world beyond.

Enterprise Virtualization enables you to extend the segmentation in the data center to the very edges of the network, where the data is consumed by users. Not only can you extend isolation, you can also view it as one contiguous service from server node to user node.

All of the tools available for measuring quality and performance have a clear view from end-to-end, rather than requiring additional tools to aggregate and correlate metrics across the three different islands of technology. Not to mention, Enterprise Virtualization allows you to significantly reduce the number of touch points while provisioning and troubleshooting, thus minimizing the likelihood of down time due to human error.

Just like that limb-dropping elm can avoid the chainsaw, your enterprise can avoid being cut down in its prime. You see, it was a problem in the ecosystem that would have eventually killed all the trees through their intertwined root systems. It was lurking beneath the surface, but the arborist took a step back to see the whole forest, and then recognized and treated the real issue. Likewise, you need to make sure that someone is looking at your forest of IT challenges … not just banging their head on a single tree.