Page 2 of 2 FirstFirst 12
Results 16 to 23 of 23

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

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

  2. #17
    Join Date
    Nov 2006
    Location
    Anderson, IN
    Posts
    884

    documentation

    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.

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

    Angry

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

  4. #19
    Join Date
    Nov 2006
    Location
    Anderson, IN
    Posts
    884

    base handler documentation

    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.

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

  6. #21
    Join Date
    Nov 2006
    Location
    Anderson, IN
    Posts
    884

    Hmm...

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

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

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

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
  •