[cisco-voip] HTTP Response for HTTP Triggered Script

Wed Jan 29 10:17:30 EST 2020

Just the synchronous radio button on the trigger step, you want async, so
you can end your http script quickly for the benefit of your web server guy.

The rest will be the context tab, where you'll pass any form data you
collected about the user (i.e., name, number, email, etc.)

>From that point forward the two remaining apps (init and q) can share that
data by way of the Contact variable you'll create with the Place Call
step.  That Contact is the same Contact as the Triggering Contact in the Q
script, and therefore, any Session or Enterprise data you store in one,
will be accessible by the other.

On Wed, Jan 29, 2020 at 7:34 AM Matthew Loraditch <
MLoraditch at heliontechnologies.com> wrote:

> Re the Trigger Application/Get Trigger Info steps, outside of the
> variables I’m passing on the context tab, does anything on the general tab
> of get trigger info matter?
>
>
>
> I don’t see why I’d need to store any of that data for my purposes?
>
>
>
>
>
>
>
> Matthew Loraditch
> Sr. Network Engineer
> p: *443.541.1518* <443.541.1518>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>  |
> e: *MLoraditch at heliontechnologies.com* <MLoraditch at heliontechnologies.com>
> [image: Helion Technologies] <http://www.heliontechnologies.com/>
> [image: Facebook] <https://facebook.com/heliontech>
> [image: Twitter] <https://twitter.com/heliontech>
> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>
> *From:* Matthew Loraditch <MLoraditch at heliontechnologies.com>
> *Sent:* Tuesday, January 28, 2020 4:15 PM
> *To:* Anthony Holloway <avholloway+cisco-voip at gmail.com>
> *Cc:* Johnson, Tim <johns10t at cmich.edu>; Cisco VoIP Group <
> cisco-voip at puck.nether.net>
> *Subject:* RE: [cisco-voip] HTTP Response for HTTP Triggered Script
>
>
>
> That sounds like way more fun than I’m willing to have!
>
>
>
>
>
> *Matthew Loraditch***
>
> *Sr. Network Engineer*
>
> p: *443.541.1518* <443.541.1518>
>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>
>
>  |
>
> e: *MLoraditch at heliontechnologies.com* <MLoraditch at heliontechnologies.com>
>
> [image: Helion Technologies] <http://www.heliontechnologies.com/>
>
> [image: Facebook] <https://facebook.com/heliontech>
>
> [image: Twitter] <https://twitter.com/heliontech>
>
> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>
> *From:* Anthony Holloway <avholloway+cisco-voip at gmail.com>
> *Sent:* Tuesday, January 28, 2020 3:59 PM
> *To:* Matthew Loraditch <MLoraditch at heliontechnologies.com>
> *Cc:* Johnson, Tim <johns10t at cmich.edu>; Cisco VoIP Group <
> cisco-voip at puck.nether.net>
> *Subject:* Re: [cisco-voip] HTTP Response for HTTP Triggered Script
>
>
>
> [EXTERNAL]
>
>
>
> I mean, you could probably contain it all in a single app script and by
> inspecting the triggering events/data, figure out which phase you're on.
>
>
>
> E.g., If trigger is HTTP Trigger then Phase 1; If Trigger is JTAPI
> extension 1000, then Phase 3, else Phase 2
>
>
>
> There's probably something to be concerned about when it comes to packing
> so much into such a small space, and troubleshooting issues might be
> harder, but I bet its achievable.
>
>
>
> On Tue, Jan 28, 2020 at 9:40 AM Matthew Loraditch <
> MLoraditch at heliontechnologies.com> wrote:
>
> So basically I need 3 separate applications. The HTTP Trigger to take the
> input then pass the input to another application that then places the call
> into the queue that’s in a third application.
>
>
>
>
>
> *Matthew Loraditch***
>
> *Sr. Network Engineer*
>
> p: *443.541.1518* <443.541.1518>
>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>
>
>  |
>
> e: *MLoraditch at heliontechnologies.com* <MLoraditch at heliontechnologies.com>
>
> [image: Helion Technologies] <http://www.heliontechnologies.com/>
>
> [image: Facebook] <https://facebook.com/heliontech>
>
> [image: Twitter] <https://twitter.com/heliontech>
>
> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>
> *From:* Anthony Holloway <avholloway+cisco-voip at gmail.com>
> *Sent:* Tuesday, January 28, 2020 10:24 AM
> *To:* Johnson, Tim <johns10t at cmich.edu>
> *Cc:* Matthew Loraditch <MLoraditch at heliontechnologies.com>; Cisco VoIP
> Group <cisco-voip at puck.nether.net>
> *Subject:* Re: [cisco-voip] HTTP Response for HTTP Triggered Script
>
>
>
> [EXTERNAL]
>
>
>
> Tim is correct: this is normal from my experience too.
>
>
>
> I feel partly responsible for your woes, since I think you found that
> solution from me pointing out the script repository online.
>
>
>
> Thinking about it some more, I think I would have the HTTP Triggered
> Application use the Trigger Application step in async mode, to start the
> initial callback feature, and then it can just End almost immediately.
>
>
>
> I through together this quick and dirty MS Paint representation of it:
>
>
>
>
>
> There's like a dozen ways to solve this, and this is just one of them.
> Some details are left out of the drawing on purpose, so if you get stuck,
> let's keep this thread going.
>
>
>
>
>
> On Tue, Jan 28, 2020, 7:14 AM Johnson, Tim <johns10t at cmich.edu> wrote:
>
> As far as my experience, this is “normal” for UCCX. Yes, I believe the
> request stays open until the script ends. I believe we opened up a TAC case
> about it a year or two ago but I don’t believe it went anywhere.
>
>
>
> *From:* cisco-voip <cisco-voip-bounces at puck.nether.net> *On Behalf Of *Matthew
> Loraditch
> *Sent:* Tuesday, January 28, 2020 8:06 AM
> *To:* cisco-voip at puck.nether.net
> *Subject:* [cisco-voip] HTTP Response for HTTP Triggered Script
>
>
>
> Got the following comment from the developer who is writing an app that
> will queue a call via http trigger:
>
> *It seems like the MobileApp integration is accepting my request, spits
> back some HTML, but the HTTP request remains open until the queued call is
> answered.*
>
>
>
> *Ideally, that HTTP request would be closed with a successful HTTP status
> code (e.g. HTTP 200) when the call was queued, so that I can report back to
> the user that they can wait for a callback. *
>
>
>
> I understand his problem, but I see no way  of fixing it. The send http
> response command doesn’t seem to have any settings but the doc sent back.
> Is this normal behavior or can I do something with the doc being sent back
> to make it work?
>
>
>
>
>
> *Matthew Loraditch***
>
> *Sr. Network Engineer*
>
> p: *443.541.1518* <443.541.1518>
>
> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>
>
>  |
>
> e: *MLoraditch at heliontechnologies.com* <MLoraditch at heliontechnologies.com>
>
>   <http://www.heliontechnologies.com/>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> <http://www.heliontechnologies.com/>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200129/5100d31b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image009.png
Type: image/png
Size: 431 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200129/5100d31b/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image010.png
Type: image/png
Size: 561 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200129/5100d31b/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image011.png
Type: image/png
Size: 444 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200129/5100d31b/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image012.jpg
Type: image/jpeg
Size: 19523 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200129/5100d31b/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image013.png
Type: image/png
Size: 6884 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200129/5100d31b/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image014.png
Type: image/png
Size: 19372 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200129/5100d31b/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 6884 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200129/5100d31b/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image092925.png
Type: image/png
Size: 9409 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200129/5100d31b/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image934676.png
Type: image/png
Size: 431 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200129/5100d31b/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image102066.png
Type: image/png
Size: 561 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200129/5100d31b/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image195650.png
Type: image/png
Size: 444 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200129/5100d31b/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image326158.jpg
Type: image/jpeg
Size: 19523 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200129/5100d31b/attachment-0001.jpg>