You can define open and close functions, which are special user functions, so that your custom server is notified when a state table performs an OpenHostServerLink action or a CloseHostServerLink action associated with that custom server.
Define the names of your open and close functions on the custom server window. How to do this is included in the procedure in Defining the main() function.
Your open and close functions must conform to the prototypes:
void OpenFuncName (short link_id)
void CloseFuncName (short link_id)
These functions are allocated func_ids in the system-generated header file, customservername_hdr.h. As with initialization and termination functions, don’t define open and close functions as user functions because they cannot be used for SendData actions in the state table. You can, however, call custom server routines from them.
Messages specifying either of the func_ids appear on the message queue just like messages from a channel process or another custom server. Use CA_Receive_DT_Msg() and CA_Get_DT_Parameters() to handle these messages. There is no equivalent CA_Send_DT_Msg() or CA_Put_DT_Parameters(), because the functions return void.
A system-generated main() includes code to handle these two functions, just like normal custom server user functions.
If you don’t define the name of the open function or the close function on the custom server window, your custom server will not receive notification of OpenHostServerLink or CloseHostServerLink actions. No error is logged. Custom servers built on releases of Blueworx Voice Response before Release 2 won’t be notified.
Note that the close event is received whether the link is closed explicitly using a CloseHostServerLink action, or implicitly by termination of the state table by CloseEverything.
When an open or a close event is received, Blueworx Voice Response cleans up any pending requests that have been processed by CA_Get_DT_Parameters(). This ensures that internal buffers are freed, and that data pertaining to a previous call is not mistakenly delivered to a subsequent user of the same channel process. However, requests which have already been received but have not been processed by CA_Get_DT_Parameters() are not flushed. This is because the request may contain vital record data (for example, billing information) which must persist until the custom server has read it, regardless of whether the link has been closed subsequently. If the caller attempts to reply to such messages, their CA_Put_DT_Parameters() will fail with a CA_NO_MSG_RECV. If such messages are present when a subsequent open event specifying the same link_id is received, then an error (20018) is logged to warn of this situation.