Page 1 of 2 12 LastLast
Results 1 to 15 of 23

Thread: Is it just me, or is the Dependency tool totally unreliable?

  1. #1
    Join Date
    Jul 2016
    Location
    Phoenix, AZ
    Posts
    142

    Angry Is it just me, or is the Dependency tool totally unreliable?

    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.

    Screen Shot PM 019.PNG

  2. #2
    Join Date
    Jun 2007
    Location
    Milwaukee, WI
    Posts
    1,207
    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:
    Code:
    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.

  3. #3
    Join Date
    Jul 2016
    Location
    Phoenix, AZ
    Posts
    142
    Quote Originally Posted by MarkT View Post
    they told me that dependency viewer should be accurate
    I want to live in Theory, everything works there...

    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

  4. #4
    Join Date
    Oct 2002
    Location
    Indianapolis
    Posts
    2,044
    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).
    George Ganahl
    Principal Education Technology Consultant

  5. #5
    Join Date
    Jul 2016
    Location
    Phoenix, AZ
    Posts
    142
    Quote Originally Posted by GGanahl View Post
    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...

    Screen Shot PM 025.PNG

    [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]
    Last edited by samandiriel; April 14th, 2017 at 16:50. Reason: Added screenshot of admin view

  6. #6
    Join Date
    Jan 2003
    Location
    Fort Worth, TX
    Posts
    192
    [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.
    Tim Cannon

  7. #7
    Join Date
    Jul 2016
    Location
    Phoenix, AZ
    Posts
    142

    Angry Haven't seen THIS particular screw up before...

    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

    How can one get Genesys to pay attention to / fix this???

    Screen Shot 10-10-17 at 09.44 AM 001.PNG

  8. #8
    Join Date
    Oct 2002
    Location
    Indianapolis
    Posts
    2,044
    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).
    George Ganahl
    Principal Education Technology Consultant

  9. #9
    Join Date
    Jul 2016
    Location
    Phoenix, AZ
    Posts
    142

    Thumbs up

    Quote Originally Posted by GGanahl View Post
    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.

  10. #10
    Join Date
    Oct 2002
    Location
    Indianapolis
    Posts
    2,044
    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!

    Quote Originally Posted by samandiriel View Post
    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 :-)
    George Ganahl
    Principal Education Technology Consultant

  11. #11
    Join Date
    Jul 2016
    Location
    Phoenix, AZ
    Posts
    142
    Quote Originally Posted by GGanahl View Post
    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

  12. #12
    Join Date
    Oct 2002
    Location
    Indianapolis
    Posts
    2,044
    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.
    George Ganahl
    Principal Education Technology Consultant

  13. #13
    Join Date
    Jul 2016
    Location
    Phoenix, AZ
    Posts
    142

    Cool

    Quote Originally Posted by GGanahl View Post
    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!

    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!

  14. #14
    Join Date
    Oct 2002
    Location
    Indianapolis
    Posts
    2,044
    Handler development becomes a kind of brotherhood...
    George Ganahl
    Principal Education Technology Consultant

  15. #15
    Join Date
    Jul 2016
    Location
    Phoenix, AZ
    Posts
    142
    Quote Originally Posted by GGanahl View Post
    Handler development becomes a kind of brotherhood...
    I think it's more a Stockholm syndrome kind of thing, myself...

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •