We've since noticed an error in system out stating that the framework wasn't able to access the file "Error accessing {file}, using empty configuration file". Besides the fact that this is being logged to stdout vs properly funneled through a logging framework, I see no exceptions being printed that would give clues as to what exactly went wrong. Is your code eating an exception? I'd advise fixing that in all places and logging via a framework such as SLF4J if you do.

~Matt

ShwetaBehere wrote:Yes, OD 7 does support WAS 8.5.5

ShwetaBehere, do you work for Avaya (i.e. can this be considered an official statement)?

Hi Wilson,

It's good to hear that these sorts of improvements are being made. Unfortunate that they will not be in version 7, but at least that they're being targeted for 8.

As for flows, we do in fact use a strategy of having developers work in one flow at a time as described in my OP. Unfortunately this isn't really sufficient as is, and I actually do see a better way around it.

As I also described in my OP, in my view Orchestration Designer is touching the flow files in unnecessary ways. To quote myself, "I made a change to one prompt and collect node to add a No Match handler recently, a very basic change/addition. When I'm ready to commit my changes, my diffing tool is half full of changes within the file. 3 entire <FlowNode>s are relocated within the file. I made a change within one node and 3 <FlowNode>s were moved." The first and most obvious fix here is to not shuffle <FlowNode> elements. I don't understand why OD is doing this, or why it can't be fixed. This is part of what makes merging these flow files a nightmare. Humans don't shuffle entire xml files when a change is made to one line, why should OD? Why can't OD just add new <FlowNode>s to the end of the <FlowGraph> element and modify <FlowNode>s in place? Same goes with everything within a <FlowNode> itself, if anything is added, just put it at the end and don't shuffle the <FlowNode>. That one change would make a huge difference.

You also mentioned the graph positioning information in the flow files, which brings up another good question that I'd like to pose. That being, if it's causing a problem with concurrent development, why is it being intermingled with data that's actually important? My opinion, put it in a different file, since to me it's not crucial information, not even important. For example, for those that don't develop concurrently, they won't even care. A positioning and node connection data file will just be another file that's committed when changes are made, no big deal. For those that develop concurrently, hopefully conflicts don't arise, and they too will also never know the difference. But in the case where a team develops concurrently, but conflicts do occur, the worst that happens is the file is conflicted beyond the point that it's worth resolving, they delete the file, OD plops the nodes on the graph in some whatever way makes them legible. The team can then pretty things back up. It would be a nuisance, but much less of a deal in comparison to reworking Data nodes and getting the comparison logic right because it at least allows the possibility of concurrent development.

And one last piece of input from me is to clarify that when I say concurrent development, I'm talking not only about multiple people within a project, but multiple projects as well. I just wanted to clarify since part of your response mentioned having developers work in different flow files, which to me sounds like you're thinking in terms of one project multiple people, but I'm thinking in terms of not only that, but multiple projects with multiple people as well. Our development has already been limited by this, where there is more than one feature our clients want, we can start coding, but they don't yet know what will take priority and what will deploy first. In other development, anyone who's sane would create feature branches and keep a clean mainline so that when the feature and the clients are ready, the branch merges to the mainline and the change is deployed. This though is beyond reason when two features both require changes to a flow file.

To sum up, I'm glad there is discussion about this at Avaya, and within the OD team specifically. I think major improvements can be made so that concurrent development is possible and given your response to me I'm hopeful that those changes will happen. Even if we have to wait for version 8 :)

I would like to add my thoughts, and I'm sure I'm not alone in the world of concurrent development, that I feel like the Orchestration Designer plugin was created without consideration of version control systems and concurrent development. Now, granted it is difficult for concurrent development of any auto generated code, but this implementation seems to have some obvious pitfalls.

One of the worst examples is the project.variables file. I've seen in my development that if I even make changes to a flow, this file can get updated. Which seems bad enough that an unrelated file gets touched, but then your plugin will reorganize the entire file. <policy> tags for every variable are shifted, and when I diff my working copy with the repo my diffing tool is literally filled with pointless modifications. That's bad for one commit, horrible for branches that have more than one developer actively developing, and prohibitive to concurrent branch development.

Another example that's almost as bad are flow files. While the ills of editing flow files can be reduced by creating cohesive and encapsulating flows, they're still very prone to unnecessary modification which creates diffing/merging nightmares. For example, I have a flow file containing 7 nodes, one of which is the Begin node, and 2 more are return nodes (so 4 meaningful nodes). I made a change to one prompt and collect node to add a No Match handler recently, a very basic change/addition. When I'm ready to commit my changes, my diffing tool is half full of changes within the file. 3 entire <FlowNode>s are relocated within the file. I made a change within one node and 3 <FlowNodes> were moved. Why would the plugin make that many changes? Again, that's bad for one commit, horrible for branches that have more than one developer actively developing, and prohibitive to concurrent branch development.

One more example that I can think of off the top of my head is .speechplugin in the project root, which I will from time to time see get edited with changes that appear to shuffle the contents for the file.

There are probably other examples which I do not have the time to recall and write about here, but I hope the above illustrates my point. I feel like there are major areas for improvement in this plugin which will allow developers to properly use version control in a concurrent development environment. Why are files being shuffled wholesale? Why can't this plugin be developed to modify as little xml as possible? Your users are smart enough to read xml, and smart enough to merge your flow files, and would love to not be held back by ridiculous automatic file modifications. I hope these suggestions are taken seriously as well, because any development team that's large enough to buy into the Avaya platform surely has enough going on to have current development at one point or another. If this happens to get views and you're reading this message thinking the same things and experiencing the same pain, please contribute your thoughts.

Thank you,
Matt

I was hoping to get the entire VXML response. Similar to our website, we'd like to get a view of the entire confirmation "page" that we present to our customers, but if what I'm hoping for is unattainable I'll at the very least be logging the payment amount.

Is it possible to log a VXML response for only one prompt/page? I know that turning the the ddrt.properties showvxml property to enabled will turn on VXML logging for all HTTP responses, but what if I only want one page, or certain pages, to be logged?

For example, we don't need to log VXML responses for when customers hear our main menu, but we would like to log all VXML responses for our payment confirmation page so that we can hold up our end in payment disputes.

Can this be done?

Thanks,
Matt

re-generating the application worked like a charm. I will say I don't think a step like this should be necessary, but regardless your near 3 yr old suggestion helped. Thank you!

Wilson, on Aug 22 2012 5:23PM you asked if this issue was caused by "cutting off the communication between the app server and vmps." At that time that is not how we had replicated the issue, but it turns out this also causes our issue.

This Monday, our VPMS was restarted around 4:30PM. Exactly at this time, we experienced the exact same symptoms that were listed earlier: there was no vpAppLogClient.log activity, no savereport.log activity, our production CPU usage spiked, and there was absolutely no evidence of socket communication to VPMS from any of our app server nodes the VPMS. This was the case until all JVMs were restarted.

This is a VP application detail report, filtered by session. I've provided a little more of the log, but I'm not concerned about anything after the -- node entry. PrepareSystemData and everything after corresponds to nodes we've added in DD so I know what those represent, I know Start is the servlet where VP supplies DD apps with call session info (ANI, DNIS, etc.), so what I really want to know is what is "--" and what part of a Dialogue Designer app does it represent.

8/6/12 8:10:14 AM   Info   Prod IVR   Framework   Node Entry   :Authentication-Begin   
8/6/12 8:10:14 AM   Info   Prod IVR   Framework   Node Entry   :Authentication   
8/6/12 8:10:14 AM   Info   Prod IVR   Framework   Node Entry   :PrepareSystemData   
8/6/12 8:10:14 AM   Info   Prod IVR   Framework   Node Entry   :Start   
8/6/12 8:10:13 AM   Info   Prod IVR   Framework   Node Entry   --   

When I view the application detail for a session in VP, I'm seeing the following at the beginning:

8/2/12 1:45:20 PM   Info   Prod IVR   Framework   Node Entry   :Start   
8/2/12 1:45:09 PM   Info   Prod IVR   Framework   Node Entry   --   

I understand Start is the /Start servlet that begins a session in a Dialogue Designer app, but what does the double dash (--) represent in a Dialogue Designer app?

I think I may have not been explicit enough in saying that these strings of characters are built at runtime and are unique every time, which is why I'm using an AudioVariable.

Would your suggested solution of using "your own phrases and explicitly add the silence phrases in between" remain the same given this that the string to be played is dynamic, or would you suggest some other solution?

And when I say below that "it had no effect on the spacing between characters," I mean that I gave an AudioVariable the value "X Y Z" but characters are still spoken one right after the other (same as if it were "XYZ") without any pause in between characters.

But unless your framework somehow supports that, I really can't, because I don't control the VXML that's being created, your framework does.

I'm hoping you can tell me there either is or isn't a way that this can be done with the Dialogue Designer framework. And, if there isn't a way, I'd like to suggest that there be a way. (Maybe there already is in OD 6, idk).

FYI, I tried a hack of adding spaces in between the characters that are being spoken, but it had no effect on the spacing between characters.

We are setting inflection, but my question is not about inflection.

My question is can I put space in between the speaking of each character? For example, when given the string "3D8CX" ideally I would like to have it do the following:

play the "3" wav file
wait 500ms
play the "D" wav file
wait 500ms
play the "8" wav file
wait 500ms
play the "C" wav file
wait 500ms
play the "X" wav file

Is there a way to control how quickly an audio variable is played back? For example, we have a confirmation code being played through an AudioVariable where the format is "Spelling characters" and we would like to have the characters played either slower or with more time in between each character. How can this be accomplished?