cisco.uc.cuae.legacy
Class RemoteHttpClient
java.lang.Object
etch.bindings.java.support.RemoteBase
cisco.uc.cuae.legacy.RemoteHttp
cisco.uc.cuae.legacy.RemoteHttpClient
- All Implemented Interfaces:
- CuaeCommon, CuaeCommonClient, Http, HttpClient
public final class RemoteHttpClient
- extends RemoteHttp
- implements HttpClient
Call to message translator for HttpClient.
|
Constructor Summary |
RemoteHttpClient(etch.bindings.java.support.DeliveryService svc,
etch.bindings.java.msg.ValueFactory vf)
Constructs the RemoteHttpClient. |
| Methods inherited from class etch.bindings.java.support.RemoteBase |
_begincall, _endcall, _newMessage, _send, _start, _startAndWaitUp, _stop, _stopAndWaitDown, _transportControl, _transportNotify, _transportQuery, _waitDown, _waitUp |
| Methods inherited from class java.lang.Object |
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
_async
public final RemoteHttpClient._Async _async
RemoteHttpClient._Async class instance used to hide asynchronous message
implementation. Use this to invoke the asynchronous message
implementations.
_inner
@Deprecated
public final RemoteHttpClient._Async _inner
- Deprecated.
RemoteHttpClient._Async class instance used to hide asynchronous message
implementation. This is here for backwards compatibility only, use
_async instead.
RemoteHttpClient
public RemoteHttpClient(etch.bindings.java.support.DeliveryService svc,
etch.bindings.java.msg.ValueFactory vf)
- Constructs the RemoteHttpClient.
- Parameters:
svc - vf -
gotRequest
public final void gotRequest(java.lang.String sessionId,
Http.GotRequestOptions options)
- Description copied from interface:
HttpClient
- GotRequest is fired whenever an HTTP request sent to the application server
is routed to a script.
The HTTP Provider listens on port 8000 for script-bound HTTP requests. This
port is not configurable.
The HTTP Provider does not support HTTPS.
If one does not send a response with their script within 5 minutes, the
HTTP provider will automatically send a 404 back to the client.
The GotRequest event allows one to build scripts with HTTP server
capabilities for any well-formed HTTP client, such as modern web browsers,
Cisco IP phones, and HTTP client libraries in development environments. The
script which receives the HTTP request should in general be sure to respond
to the request with the SendResponse action.
The GotRequest event can be either a triggering event or a non-triggering
event, meaning an HTTP request can either cause a script to initiate and
begin executing, or an HTTP request can route to an already-running script.
The determination if an incoming HTTP request should be treated as a
triggering event or a non-triggering event is based on the presence of
session information in the request. Specifically, the following describes
how HTTP requests are processed by the HTTP provider:
If the HTTP request contains no session information, the HTTP request is
sent up to the Application Runtime Environment as a triggering event, at
which point:
If the HTTP request does contain session information, meaning that either
a cookie, query parameter, or header with the name of metreosSessionId
has the RoutingGuid of a script as its value, then the event is sent to
the Application Runtime Environment as a non-triggering event. The event
is routed to a script with a RoutingGuid matching that found in the
session information from the request, at which point:
The type QueryParamCollection can be used to easily access query parameters
associated with the incoming HTTP request.
The GotRequest has all headers supplied as custom event parameters. To
access these headers, one must create a local variable in the designer and
initialize the variable, supplying the name of the header of interest as
the value of the InitializeWith property. Be sure to also specify the
DefaultValue property so that the script starts gracefully in the case that
the header is not present in the request. One can also use the value of the
default value parameter to determine if the header is present or not in the
request--by comparing the value of the local variable to the value of the
default value, one can determine if it was initialized with the header
value or the default value.
- Specified by:
gotRequest in interface HttpClient
- Parameters:
sessionId - The session Id for this method calloptions - An object holding all the optional parameters
sessionExpired
public final void sessionExpired(java.lang.String sessionId,
Http.SessionExpiredOptions options)
- Description copied from interface:
HttpClient
- SessionExpired is sent to any scripts that have been deemed inactive.
None.
The SessionExpired is sent to a script if the following criteria is
satisfied:
The script was initiated by the HTTP Provider GotRequest.
The script has received no subsequent non-triggering GotRequest events
for an amount of time equal to or greater than the cleanup period of the
HTTP provider, which is by default 20 minutes.
The script has not executed the SessionEnd action.
The HTTP provider has never received a no handler in response to sending
a SessionExpired event. The HTTP Provider uses the occurrence of a no
handler to indicate that the script is no longer running, or that it does
not define an event handler for SessionExpired. In either case, this
means to the HTTP provider that the script instance does not need to be
informed of a session expired event and that it will no longer attempt to
send the SessionExpired event to that script instance.
Upon receiving the SessionExpired event, what should be done is entirely up
to the developer; the application server places no expectations or
requirements on the script instance. Specifically, it is not required that
the script instance come to an end when SessionExpired occurs; however, it
is reasonable to expect that a large percentage of scripts will indeed end
with the occurrence of this event, since it indicates inactivity of over 20
minutes. Couple this amount of inactivity with the session-less nature of
HTTP and the inherent difficulty of tracking the state of the user of the
application, one can see why most scripts would end when this event occurs.
If the developer chooses to not end the script upon receiving the
SessionExpired event, then SessionExpired events will continue to fire for
that script until one of the conditions is met in the above list.
If you end a script at any point, one can use the SessionEnd action to
indicate to the HTTP Provider that it can release the session from it's
memory. In other words, it no longer will track this script instance any
longer.
- Specified by:
sessionExpired in interface HttpClient
- Parameters:
sessionId - The session Id for this method calloptions - An object holding all the optional parameters
Copyright © 2008. All Rights Reserved.