I've had several instances where the dependency tool simply doesn't list all the dependencies. This has been extremely problematic when trying to hunt down subroutine usage due to changing parameters. Does anyone know how to get this tool to actually work properly, or is it just garbage? As an example, here's a screenshot of my attempt today to find the handler associated with a particular button and the tool failing to show the associated handler. [ATTACH]810[/ATTACH]

Ive also seen some really strange behavior in dependency viewer where it shows a subroutine is not called by anything but like you I can pull up a handler and see the subroutine being called. I asked Genesys support about this many years ago and they told me that dependency viewer should be accurate. If you look closely when you publish a handler there is a step where it writes all of the dependency information to the registry. If you dig around you can find the dependency information stored in the registry somewhere. Here is a little trick I picked up over the years of trying to find specific information in the handlers. I create a bat file named output.bat and I drop this into the bat file:find /i "whatyouwant" *.class > output.txt You can type in whatever you are looking for between the "". The bat file will dump it's results to the output.txt file which will show each handler and if the value exists in the handler it will note where the value was found in the handler.

Originally posted by MarkT;35170
they told me that dependency viewer should be accurate

I want to live in Theory, everything works there... :p The batch file is a good trick, thanks - I shall definitely give that a try, though seeing as dependency viewer *should* be accurate I presume I never will have the opportunity to do so ;)

Regarding the inaccurate info...did you also look at what is shown in Interaction Administrator under Interaction Processor>Handlers? I am wondering if the handler info is properly registered there (since that's is the info Dependency Viewer is pulling from, and builds from every time you change the selected view in Dependency Viewer).

Originally posted by GGanahl;35174
Regarding the inaccurate info...did you also look at what is shown in Interaction Administrator under Interaction Processor>Handlers? I am wondering if the handler info is properly registered there (since that's is the info Dependency Viewer is pulling from, and builds from every time you change the selected view in Dependency Viewer).

No, I hadn't looked at that. It's certainly listed there in Admin, but I have no idea what that connotes... [ATTACH]811[/ATTACH] [rant]I don't really have the time or resources to be regression testing every function of what is allegedly a mature and actively developed third party product every time I use one of those functions, quite aside from the fact that I shouldn't have to be using my employer's time to constantly check whether another company's tool has dumped in it's diapers every time I use it :/ [/rant]

[rant]I don't really have the time or resources to be regression testing every function of what is allegedly a mature and actively developed third party product every time I use one of those functions, quite aside from the fact that I shouldn't have to be using my employer's time to constantly check whether another company's tool has dumped in it's diapers every time I use it :/ [/rant][/QUOTE] +1 The dependency tool has never worked for custom handlers at any place I have published handlers. When I opened tickets, they have been closed due to lack of progress between the VAR and I3. I gave up on this years ago.

Apparently it's now reporting dependencies for handlers that aren't even published... FF_GetInteractionDetails and FF_GetLastInteractionByClientPhone show up in the dependency tool, but aren't in the server archive for downloading into Designer :mad: How can one get Genesys to pay attention to / fix this??? [ATTACH]882[/ATTACH]

Question for you...did you create those custom handlers that are missing, or did you inherit the system with all that stuff (perhaps custom work done by PSO, whoever)? I ask because what you are showing is a symptom of someone having published those handlers at one time, so they are still registered with Interaction Processor, but then someone deleted the .ihd files from \I3\IC\Server\Handlers without deleting them from the Handlers container in Interaction Administrator. If you look in the \I3\IC\Server\Handlers folder, do you see .class versions of those handlers still in there? Just curious. You can't re-create the .ihd from the .class, but their being there without the .ihd files is another indication that someone didn't clean up those custom handlers properly. For future reference, the Dependency Viewer is just looking for .ihd files in that \I3\IC\Server\Handlers folder (which is where IC stores a copy of the .ihd when you publish from Interaction Designer), so you can just browse directly to that folder to look for the currently-published version of the .ihd for any handler (presuming no one manually deleted it).

Originally posted by GGanahl;35970
Question for you...did you create those custom handlers that are missing, or did you inherit the system with all that stuff (perhaps custom work done by PSO, whoever)? I ask because what you are showing is a symptom of someone having published those handlers at one time, so they are still registered with Interaction Processor, but then someone deleted the .ihd files from \I3\IC\Server\Handlers without deleting them from the Handlers container in Interaction Administrator. If you look in the \I3\IC\Server\Handlers folder, do you see .class versions of those handlers still in there? Just curious. You can't re-create the .ihd from the .class, but their being there without the .ihd files is another indication that someone didn't clean up those custom handlers properly. For future reference, the Dependency Viewer is just looking for .ihd files in that \I3\IC\Server\Handlers folder (which is where IC stores a copy of the .ihd when you publish from Interaction Designer), so you can just browse directly to that folder to look for the currently-published version of the .ihd for any handler (presuming no one manually deleted it).

Interesting. I didn't inherit this, but I'm not the only person working on the handlers. I myself always go into IA and delete any references to ones that I want gone. I shall have to have a word... thanks, G! Going to the handler dir won't tell me anything about the tools in use in handlers unfortunately.

Interesting. I didn't inherit this, but I'm not the only person working on the handlers. I myself always go into IA and delete any references to ones that I want gone. I shall have to have a word... thanks, G!

Originally posted by samandiriel;35971
Going to the handler dir won't tell me anything about the tools in use in handlers unfortunately.

Sure it will...just grep through the .class files for the tool you want. They're just text files :-)

Originally posted by GGanahl;35972
Interesting. I didn't inherit this, but I'm not the only person working on the handlers. I myself always go into IA and delete any references to ones that I want gone. I shall have to have a word... thanks, G! Sure it will...just grep through the .class files for the tool you want. They're just text files :-)

Ah, neat, thanks. Since 99% of everything ININ does is proprietary garbage that makes real dev impossible, I've just stopped looking at all for anything in a sane, sensible format anymore :D

One thing you cannot do is edit the .class files directly. They have a hash built at publish, so if you modify one of those files the handler will no longer work. Many years ago you could edit them (to change a variable data type, do some other stuff not available through Designer), but not any more. The handlers used to be Java files (hence the naming convention) but now they are "i3speak", as it were...our own language. But still text files. I realize that the tools in Interaction Designer are not all you'd like them to be. It has never been given the highest priority in Development, basically due to business decisions on where to spend the R&D money (Designer is "good enough" for most folks). I've been using it for over 18 years, so I've seen the massive improvements...but I also know how to deal with all of its quirks, and I view the pieces as tools to be used as makes sense. Then again, I'm the guy who uses the CLI to configure Cisco switches because I hate their web interface...so I use the keyboard a lot in Designer, and go right to the files and directories, and don't use Dependency Viewer for much beyond seeing which subroutines will be affected when I make a change, or to see where a specific subroutine is called from.

Originally posted by GGanahl;35976
One thing you cannot do is edit the .class files directly. They have a hash built at publish, so if you modify one of those files the handler will no longer work. Many years ago you could edit them (to change a variable data type, do some other stuff not available through Designer), but not any more. The handlers used to be Java files (hence the naming convention) but now they are "i3speak", as it were...our own language. But still text files. I realize that the tools in Interaction Designer are not all you'd like them to be. It has never been given the highest priority in Development, basically due to business decisions on where to spend the R&D money (Designer is "good enough" for most folks). I've been using it for over 18 years, so I've seen the massive improvements...but I also know how to deal with all of its quirks, and I view the pieces as tools to be used as makes sense. Then again, I'm the guy who uses the CLI to configure Cisco switches because I hate their web interface...so I use the keyboard a lot in Designer, and go right to the files and directories, and don't use Dependency Viewer for much beyond seeing which subroutines will be affected when I make a change, or to see where a specific subroutine is called from.

Oh, I understand why the tools are the way they are, but it's still frustrating - especially since that was one of the big selling points the rep talked up for us when we were being sold the system. And the fact that they are so user unfriendly just from the get go grates, as well - they were badly designed from the start, alas. I shudder to think of what it *used* to be like, if these are the massive improvements! :D A huge part of the problem is that there is so little documentation and so little help available that knowing when to use each piece and when to use non-standard tools instead (eg, grepping thru class files instead of dependency tool) is extremely problematic. It doesn't help that a lot of things are fragile, and break if you are "holding them wrong", such as when removing handlers :) I shall soldier bravely on, tho - and thanks for the kind words, G!

Handler development becomes a kind of brotherhood...

Originally posted by GGanahl;35978
Handler development becomes a kind of brotherhood...

I think it's more a Stockholm syndrome kind of thing, myself... :D

Handler development is really an art. The handler training class is good to get you the basics but there are so many finer details, or tips and tricks that the only way to truly get good at handlers is by debugging system handlers and writing your own. I certainly feel your frustration for dependency viewer's shortcomings but some of this can be addressed with decent documentation. Don't misunderstand my comment as dismissing the fact that dependency viewer should work but a little documentation on your customization goes a long way for the next guy who needs to support the system. Technical flowcharts are really helpful if you can find time to make them.

I completely agree. All custom handler modifications should be documented both eternally (flow chart, descriptions, etc.) and internally (custom handler properties dialog, and toolstep names/notes). My goal when I write any handler customizations is that the next person should be able to look at any custom handler and immediately see why it was created, then within each toolstep, see why it is there and what it is doing.

Originally posted by MarkT;35997
Handler development is really an art. The handler training class is good to get you the basics but there are so many finer details, or tips and tricks that the only way to truly get good at handlers is by debugging system handlers and writing your own. I certainly feel your frustration for dependency viewer's shortcomings but some of this can be addressed with decent documentation. Don't misunderstand my comment as dismissing the fact that dependency viewer should work but a little documentation on your customization goes a long way for the next guy who needs to support the system. Technical flowcharts are really helpful if you can find time to make them.

We actually extensively track and document customization thru our change management processes; what's frustrating is how hard it is to do so efficiently given the proprietary formats used by Genesys (even for the bloody log files!!!). Git, diff, automated deployment, change management systems integration, etc are all effectively neutered by this and it's a huge drag on development. <rant> And the lack of *any* documentation from Genesys on *system* handlers and how calls flow thru the system is a huge, huge bottleneck. Mentioning that in the handler class just got me a pained look and a shrug along with the comment that one just has to keep on doing debugs and tracing call flows on one's one. Plus there is no documentation either for the hundreds of built in subroutines; I'm sure I've reinvented the wheel a few times now as a result. I still cannot believe that a product of this age and scope that advertises itself as also being a platform for development has no developer documentation at all available on how the system actually fits together - just the very lowest level building scripting language blocks, that's it. </rant>

I also have wished for good base handler documentation, but the reality is that Genesys considers them to be proprietary code. I understand this, but it would be nice if there were some documentation that at least gives us as developers an idea of the flows involved in different scenarios and for different media types and best practices for leveraging each customization point.

One of y'all could take on the project I asked Dev to do years ago (but they never had resource to put on it, since it doesn't produce revenue)... It shouldn't bee too had to write a script of some kind (Python, whatever) that parses through the handlers in a flow and builds the "map" for you. All the files are text files, so you can parse through (based on the initial handler) and find each subroutine call. There are a few tool steps which send an event which initiates another handler (like "Station Place Call" in System_StationOffHook which generates the "Outgoing Call Request" event and starts the System_InitiateCallRequest handler). You could parse for those and build the map using that info as well. I almost got them to do it...until the designated developer got too busy with another project :-(

Sounds like a good project to attend to - I'll put it on my list.

I took the handler class years ago (Certified on 2.4) and they covered in the class how the calls flow through the system. Also if I remember correctly there was an old document which mapped out the system handlers but I don't think it was ever updated with the more recent versions of CIC. As much as people like to complain about the help files the ones in handlers are pretty good and after you spend time writing handlers you get a pretty good idea where to look when you want to make a customization. I will admit that handler development seems to be a skill that is pretty slim pickings in the community and if you want to learn how to do it you either need a mentor to help you or a very patient employer to let you spend lots of time learning how everything connects.

Yeah...unfortunately, Dev stopped producing those Handler Maps many years ago. They were quite useful, and folks have asked about them ever since. When I first joined Interactive in 1999 (version 1.2f), I spent days debugging inbound and outbound handlers, mapping things out by hand, in order to gain a deep understanding of the functionality. They have become much more complicated since then, and some of the functionality doesn't even make sense any more (like stuff in System_StationOffHook that is specific to board-based systems that don't exist in 4.0 and later). We used to have the Advanced Handlers class that I built...but not enough people actually attended to make it worth keeping on the books. There are some useful command-line options for IDU.exe and EicPublisherU.exe documented in the Interaction Designer Help, under the Batch Publishing topic and the "Starting Interaction Designer with command line parameters" topic.