PureConnect

 View Only

Discussion Thread View
  • 1.  Handler version control

    Posted 04-04-2017 14:41
    I am looking for some guidance with Handlers and version control. In the past I have always saved the handlers off and maintained a soft versioning with the initial step of a handler. This works ok until you get a touch lazy or others don't know the procedures. So I am looking for some advice from others that may have already tackled this. I can see where you can export the handle in xml format and that could work. With the exception of not being able to import the xml back into Designer. The only option that I can see would be to do an export into xml, then upload the xml and the compiled handler file to the version control system being used. Thanks for any time given to this.


  • 2.  RE: Handler version control

    Posted 04-05-2017 13:34
    This topic comes up from time to time. I don't believe anyone has come up with a reliable source control method for handler management. I usually put notes in the initiator with the date, my initials, and a description of what I changed. I have seen some people store the handlers in the custom folder and then when a handler is checked out they will copy it to a check out folder and then when the developer is done they move the handler back to the custom folder. Obviously like you mentioned if people start getting lazy or don't know how the process works then it breaks down. I also worked at a place once which had a spreadsheet with every handler in it and when someone would work on it they would comment in the spreadsheet and document their changes. After the handler was published then the notes were archived off in the spreadsheet. This worked pretty well as it was easy to update and understand.


  • 3.  RE: Handler version control

    GENESYS
    Posted 04-05-2017 21:16


  • 4.  RE: Handler version control

    Posted 04-12-2017 16:08
    Originally posted by NateDB;35113
    I am looking for some guidance with Handlers and version control. In the past I have always saved the handlers off and maintained a soft versioning with the initial step of a handler. This works ok until you get a touch lazy or others don't know the procedures. So I am looking for some advice from others that may have already tackled this. I can see where you can export the handle in xml format and that could work. With the exception of not being able to import the xml back into Designer. The only option that I can see would be to do an export into xml, then upload the xml and the compiled handler file to the version control system being used. Thanks for any time given to this.
    Our shop is using git for version control, using the proprietary ihd files rather than XML as we didn't want the overhead of export since it's useless anyway. You can use git for non-text files, you just lose some features that require readable text. It does require good communication tho, as there is no way to auto diff or merge handlers when there are conflicts (we usually either use Designer's Handler Diff tool or just open up the different versions in different Designer instances and do step by step comparisons). It's saved our butts a couple times for rolling back after finding production problems and for tracking who's worked on what, which is why we adopted it :) We're an Atlassian shop, so we use bitbucket and sourcetree for our centralized repo and client GUI: [ATTACH]809[/ATTACH]


  • 5.  RE: Handler version control

    Posted 04-12-2017 16:56
    Funnily enough, I was looking at Bitbucket for managing M$ Office documents. I found some stuff on converting Word files into Markup, which BB/Git can do a diff on (and make it look pretty) You can trigger the conversion to happen automatically when you check in. Like the XML, the markup isn't much use other than highlighting changes, so the original is also kept. So, there may be some mileage in getting an XML version of the handler so that BB/Git can do a diff between any two versions. You may even be able to get it to create the XML automagically when you check in....


  • 6.  RE: Handler version control

    Posted 04-12-2017 17:56
    Originally posted by Wierdbeard65;35167
    Funnily enough, I was looking at Bitbucket for managing M$ Office documents. I found some stuff on converting Word files into Markup, which BB/Git can do a diff on (and make it look pretty) You can trigger the conversion to happen automatically when you check in. Like the XML, the markup isn't much use other than highlighting changes, so the original is also kept. So, there may be some mileage in getting an XML version of the handler so that BB/Git can do a diff between any two versions. You may even be able to get it to create the XML automagically when you check in....
    The overhead for XML is way too high for us if it's manual, and the only way I know how to do it is via Designer. If someone knows of a command line function that could be used to automate I'd certainly be all over it :)


  • 7.  RE: Handler version control

    Posted 04-13-2017 15:28
    I have all of the same problems with code control. I store mine in TFS. I also create packages using /intermediatepublish, then publish all handlers from a batch file. It seems that you could add /HandlerOpenAutoXMLPath to the intermediate publish file to get xml documents during packaging. Then store source IHD and XML files together.


  • 8.  RE: Handler version control

    GENESYS
    Posted 04-13-2017 21:24
    How to Batch Publish Handlers The following command line will help perform a batch publish of handlers: idu.exe /LogPublishEvents /ForcePublishClose /HandlerOpenAutoXMLPath=. /IntermediatePublish:intermediatepublish.lst (or /Publish:handlers.lst) Here the functions of each of the command options: LogPublishEvents - Writes information about each handler to the Application Event log. ForcePublishClose - Forces Interaction Designed to close once the operation is complete. HandlerOpenAutoXMLPath - Generate an XML file (same content you would get from export. IntermediatePublish - Publish all files in the list file named "intermediatepublish.lst" (a list of .i3pub files, one name per line) Publish - Publish all the handlers in the list file, with each line in the list in the format {filename} [| Primary OR Monitor] If you need to designate the category for new subroutine handlers on publish, you will have to use Designer COM instead (documentation is ins the System APIs section of help.inin.com) From an old email: The idea is you’d have Interaction Designer open the desired .ihd which returns an II3IDHandler interface pointer. On that II3IDHandler interface you can call the Publish method which lets the caller set whether or not the handler is active, primary and for subroutines the caller can specify a category. This is the IDL for the Publish method: [id(0x6003001d), helpcontext(HID_II3IDHANDLER_METH_PUBLISH), helpstring("Publishes the handler to the default IC server.")] HRESULT Publish([in, optional, defaultvalue(0)] VARIANT_BOOL Activate, [in, optional, defaultvalue(0)] VARIANT_BOOL Primary, [in, optional] BSTR Category);


  • 9.  RE: Handler version control

    Posted 04-14-2017 20:40
    Originally posted by GGanahl;35176
    How to Batch Publish Handlers The following command line will help perform a batch publish of handlers: idu.exe /LogPublishEvents /ForcePublishClose /HandlerOpenAutoXMLPath=. /IntermediatePublish:intermediatepublish.lst (or /Publish:handlers.lst) Here the functions of each of the command options: LogPublishEvents - Writes information about each handler to the Application Event log. ForcePublishClose - Forces Interaction Designed to close once the operation is complete. HandlerOpenAutoXMLPath - Generate an XML file (same content you would get from export. IntermediatePublish - Publish all files in the list file named "intermediatepublish.lst" (a list of .i3pub files, one name per line) Publish - Publish all the handlers in the list file, with each line in the list in the format {filename} [| Primary OR Monitor] If you need to designate the category for new subroutine handlers on publish, you will have to use Designer COM instead (documentation is ins the System APIs section of help.inin.com) From an old email: The idea is you’d have Interaction Designer open the desired .ihd which returns an II3IDHandler interface pointer. On that II3IDHandler interface you can call the Publish method which lets the caller set whether or not the handler is active, primary and for subroutines the caller can specify a category. This is the IDL for the Publish method: [id(0x6003001d), helpcontext(HID_II3IDHANDLER_METH_PUBLISH), helpstring("Publishes the handler to the default IC server.")] HRESULT Publish([in, optional, defaultvalue(0)] VARIANT_BOOL Activate, [in, optional, defaultvalue(0)] VARIANT_BOOL Primary, [in, optional] BSTR Category);
    Thanks, that's actually useful for something else I wanted to automate! Though I don't think it would work very well for our dev process unfortunately.


  • 10.  RE: Handler version control

    Posted 04-17-2017 13:39
    Thanks all for the very useful information. I think I have enough in here to help me tighten things up a bit.


Need Help finding something?

Check out the Genesys Knowledge Network - your all-in-one access point for Genesys resources