I need to know is there any way to read/write .aef file in java with out cisco ccx editor.
Is .aef is cisco property or we can play with it.
Any help is much appreciated.
Was there ever a reply on this? I've tried a number of different methods in Java and C# and couldn't come up with one that worked so far.
Maybe Tanner replied offline, strange he didn't reply on here either. I'm going to send him a link to this thread on spark.
Hey tannerezell / [@tanner.ezell] ,
Just curious if you have had an opportunity to take a look at how to read the input stream of an .AEF file?
Where did the product ContactView Designer go ? Is this still a viable tool and is it available ?
Telecom Engineer\UC Systems
My primary goal in looking into this is to pull information for architectural drawings and such OUT of either the AEFs themselves or better, from the repository directly.
The use case is that I spend A LOT of time manually diagramming and documenting UCCX call flows and am looking for a way to automate this.
That starts with being able to figure out which reader is capable is accessing the file format.
Getting the information from the AEF isn't the problem, that part is easy. Creating some kind of diagramming documentation out of it is the challenge.
Think about the detail that exists in an AEF file, step by step. Now think about how you create your diagrams. I'd guess you do not do a 1:1 ratio of steps to shapes on your Visio, that'd be way too verbose and there are simply details you wouldn't communicate at a higher level; an application that would do this 1:1 step to shape diagram is no better than a tool that would print out the steps.
When I developed ContactView I wanted to do exactly as you suggest, build diagrams from AEFs.
After a year of work, here is a snippet of the best possible outcomes reading an AEF and producing a diagram:
This represents the accumulation of all that time and it is the best outcome we could generate. This type of output was possible on very well formatted AEF files.
In a real word scenario what we got instead was a mess, there are so many edge cases in the way that people build AEFs that is is nearly impossible to create a clean, meaningful graph. Even this snippet:
Which might look like a nice orderly graph is a mess of set steps and other low level implementation steps that provide no meaningful value to the viewer .
How do you handle fall through? How do you handle portions of code that live in total isolation, etc etc. There are so many edge cases that providing a graph that looks clean and actually conveys the information is tremendously difficult.
Once we came to this conclusion we shifted gears, said this would be an aid, build out the majority of the Visio and let you, the user, fine tune it for your audience. What we ultimately found out is that it was SLOWER for the user to edit our generated Visio into something meaningful than it was to simply create a new one from scratch using the AEF as a reference.
By now it became clear this was not a magic bullet to building documentation automatically. There isn't one. We then decided to reverse the process, start with a clear, concise, easy to understand and easy to program graph that built the AEF as the end result. In this sense, the graph, your code, your documentation are always in sync.
This is what ContactView is today,
a tool for creating meaningful, concise and clear scripts for UCCX that are self documenting.
I guarantee you that building your call flow diagrams is faster in ContactView than it is to do it in Visio; with the side benefit of getting an extremely robust script out of it.
ContactView - Visually Create AEFs for Cisco's UCCX
Thanks for the incredibly detailed reply tannerezell you've hit the nail on the head in terms of complexity of creating a UI and UX that makes sense for the average person managing scripts.
My purposes have little to do with creation on AEF's. I often have to dive into unknown call flows and it would be incredibly useful to dump an AEF into Visio, or other diagramming solution as a literal representation of what's there. That could be for technical discussion or other parts of the work that don't involve creation of AEF's. Most of what I'm talking about comes from inheriting historical applications and the need to either document them as-is or just simply have a reference that is easier to share than screen shots and notes of an AEF. Literal call flow, not logical representations, if that makes sense.
I really like the simple interface of your tool though, so will check that out in more depth once I get to a place where it makes more sense.
The question being asked in this thread though was in regards to methods necessary to read the AEF file. (Simple StreamReader, StreamReader with some sort of decoding, etc, etc.) The very basic "get textual representation of this file into some usable coding language."
You mention that's the easy part, but it's really the part that I've been stuck on, having tried some of the actually simple methods.
Thanks again for the reply.