PureConnect

 View Only
Discussion Thread View
Expand all | Collapse all

synching multithreaded handlers

  • 1.  synching multithreaded handlers

    Posted 08-01-2019 09:23
    Hi community

    lets say we have handler X which fires custom notifications (triggers another handler named Y)

    right  after the notification works (next step) -handler X activates tool step 4444

    how do i make sure steep 4444 wil be executed before handler-Y is finished ???? (which is in a different thread)

    Thanks
    #Handlers

    ------------------------------
    Avi Rozen
    Harel
    ------------------------------


  • 2.  RE: synching multithreaded handlers

    Posted 08-01-2019 09:33
    I'm not saying this is the only way, but you can do it by setting attributes on your interaction in one handler and then using Extended Get Key steps in your other handler to watch for that attribute to change on the interaction.

    An example:

    1. Hander X fires a custom notification, triggering handler Y which includes Interaction1 as a string as a part of the data sent with the notification
    2. Handler Y converts the string to a callID and assigns it as Interaction1
    3. Handler Y does what it does and then gets to an Extended Get Key step that is watching attribute "attr_wait" on Interaction1
    4. Handler X does what it needs to do before handler Y completes
    5. Handler X sets attribute "attr_wait" to a value on Interaction1
      1. The Extended Get Key is just watching for the value to change
    6. Handler Y continues

    This is how I provide audio during web service calls that take more than a second or two in handlers.  This may or may not apply to your specific use case, but I hope it is helpful.

    ------------------------------
    Aaron Lael
    State of Utah
    ------------------------------



  • 3.  RE: synching multithreaded handlers

    Posted 08-01-2019 10:33
    Edited by Avraham (Avi) Rozen 08-01-2019 10:37
    Hi Aaron,

    Appreciate your help !! :-)

    Your method seems to be terrific but i have some open issue about it :

    I assume you you play hold-on music via extended-get-key in Handler Y -isn't it dangerous doing so when handler X has active CallID as well and performing telephony operations may conflict with extended-get-key in Handler Y..

    Is'nt it is safer using extended-get-key in main thread (X)  than in handler Y ?
    Or how can i reassure that while extended-get-key is active -no other telephony operation interuppts?

    Thanks

    ------------------------------
    Avi Rozen
    Harel
    ------------------------------



  • 4.  RE: synching multithreaded handlers

    Posted 08-01-2019 10:40
    Generally speaking, the extended get key step in the handler triggered by the custom notification can only be exited by 3 events when I configure it:

    • The attribute being changed
    • A pre-set timeout being reached leading to further logic in the handler
    • The interaction disconnecting
      • This takes the failure path of the extended get key step

    You can change what key presses exit the Extended Get Key step in the configuration of the step.

    It is also important that whatever steps you are using along the way in your calling handler up to the point where you are changing your attribute have their failure and other paths accounted for.

    My example of playing music is just a generic example of how to interact between two concurrently running handlers.  You can run with this idea however you choose and I strongly recommend you write up some good test cases to play out in your development environment.

    Hopefully that clears up anything.


    ------------------------------
    Aaron Lael
    State of Utah
    ------------------------------



  • 5.  RE: synching multithreaded handlers

    Posted 08-02-2019 12:15
    I think you can accomplish this via semaphore locks however can you provide more details as to what that parallel custom notification is doing?

    ------------------------------
    Mark Tatera
    ConvergeOne

    Opinions are my own and not the views of my employer. Any suggestions or programming changes I suggest come with no warranty and should be tried at your own risk.
    ------------------------------



  • 6.  RE: synching multithreaded handlers

    Posted 08-03-2019 18:27
    REALLY dumb question here, but why don't you just make Handler Y a Subroutine, called from Handler X?

    Usually, the methodolgy you describe is used because you want Handler X to continue while Handler Y does its thing....


  • 7.  RE: synching multithreaded handlers

    Posted 08-04-2019 04:16
    Thank you Aaron for making it clearer.

    Paul, i want to accomplish something very much like as Aaron described ---> Playing music till an answer recived from WS or ODBC--something that requires time.
    It has to be done in seprate threads.

    The way i would like it to be is:
    Handler X suppose to play hold-on music (ex-get-key) when handler Y activates the operation which takes time. 

    Mark, can you think of using critical section in such a case? i don't see how .
    Locks are made to synch a single operation at a single time, in my case i want to make sure ex-get -key will be waiting before set-attribute in a different
    Handler (Y) will change its monitored value

    ------------------------------
    Avi Rozen
    Harel
    ------------------------------



  • 8.  RE: synching multithreaded handlers

    Posted 08-04-2019 10:11
    Ahhh, I see!

    That wasn't quite what you originally asked for (at least from my reading of it). It seemed you simply wanted X to start Y and do nothing until Y had finished, which would be easiest with a subroutine.

    Thanks for clarifying :-)


  • 9.  RE: synching multithreaded handlers

    Posted 08-05-2019 05:31
    Another method to accomplish this is to set the base attribute for hold audio (don't remember it off the top of my head), place the call on hold, complete web service call, and then pickup the call again. This doesn't require the complexity of an async operation.

    ------------------------------
    David Currier
    cpi.solutions
    ------------------------------



  • 10.  RE: synching multithreaded handlers

    Posted 08-05-2019 06:40
    Thank you David, i've found your method mentioned in prior posts.

    I'd still be very happy to hear (using the asinch method) ,how to reassure that extended get key will monitor attribute change BEFORE that value changes in a different thread ??! (otherwise Attribute exit won't be triggered)


    ------------------------------
    Avi Rozen
    Harel
    ------------------------------



  • 11.  RE: synching multithreaded handlers

    Posted 08-05-2019 11:44
    Avi,

    I've built quite a few IVRs over the years and whenever I have to do look ups if the request takes some time I will play a prompt (please hold while we access your info) and then put the caller on hold. From here I call the subroutine which holds the request, when it's done the subroutine returns and I pick the caller back up off hold and continue on the way.

    Now I will admit I've tried to work through some sort of asynchronous lookup so for instance if I'm looking up ANI to try to ANI match I could do it in parallel while the caller enters the IVR and hears the greeting. I started to do what it sounds like you are referring to but it became way too much work to try to implement. The error handling alone for what to do if the web service doesn't come back was a pain. Now for things like ANI matching we make really lightweight web services so they return almost instantly and don't even play a message or put the caller on hold. We also set the timeout to something real short so the caller doesn't even know this request is happening.

    If what I'm referring to is not what you are trying to do perhaps providing additional details as to the full picture of what you are trying to accomplish we may be able to provide some additional ideas.

    Thanks,

    ------------------------------
    Mark Tatera
    ConvergeOne

    Opinions are my own and not the views of my employer. Any suggestions or programming changes I suggest come with no warranty and should be tried at your own risk.
    ------------------------------



Need Help finding something?

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