HttpCommand and Conga
HttpCommand uses Conga, Dyalog's TCP/IP utility library, for communications. HttpCommand requires Conga version 3.0 or later. Conga consists of two elements:
- Two shared library files whose names begin with "conga" and are found in the Dyalog installation folder. The names of the files varies based on the platform they are running on and the specific version of Conga; for instance
conga34_64.dllandconga34ssl64.dllare the shared library files for Conga version 3.4 for the 64-bit version of Dyalog for Windows. - An APL-based API to communicate with the shared libraries. There are two versions of the API both of which are available in the
congaworkspace.- A namespace named
Congawhich was introduced with Conga version 3.0 and implements behavior that makes it easier to run multiple Conga-based utilities in the same workspace.Congais the recommended API version to use. - A namespace named
DRCwhich is retained for backward-compatibility with applications which use earlier versions of Conga.DRCshould only be used in an application where backward compatibility is necessary.
- A namespace named
The Conga API looks for a matching version of the shared libraries; as such version of the API and the shared libraries must be the same. For more information on Conga please refer to the Conga User Guide.
Default Behavior
When first run, HttpCommand will attempt find or copy the Conga API and then initialize it. HttpCommand will attempt to use the Conga version of the API in preference to the DRC version. In general, all of this is transparent to the user.
- Look in the current workspace for the Conga API:
- First look in the namespace where
HttpCommandresides for a namespace named eitherCongaorDRC, in that order. - Failing that, look in the root namespace
#for a namespace named eitherCongaorDRC, in that order.
- First look in the namespace where
- If neither version of the API is found in the current workspace,
HttpCommandwill attempt to copy the API (firstCongathenDRC) from thecongaworkspace. The API is copied into theHttpCommandclass which means there will be no additional footprint in workspace.HttpCommandwill attempt to copy the API as follows:- If the
DYALOGenvironment variable exists, use its folder. Otherwise use the folder from the command line used to start Dyalog. - If that fails, then attempt to copy from the "current" folder as determined by
⊃1 ⎕NPARTS ''
- If the
- If the API was found or successfully copied,
HttpCommandwill initialize Conga as follows:- If the
Congaversion of the API is used,HttpCommandwill initialize it with a root name of'HttpCommand'. - If the
DRCversion of the API is used,HttpCommandwill simply initialize it. AsDRCdoes not support multiple roots, care should be taken if other Conga-using utilities also reside in the workspace.
- If the
- If the API was successfully initialized, a reference to the API root can be found in
HttpCommand.LDRC.
Overriding Default Locations
There are two methods to tell HttpCommand's default behavior, both of which involve setting a shared public field in the HttpCommand class.
- If you have the
Conganamespace in your workspace in other than default locations theHttpCommandwill search,HttpCommand.CongaRefcan be used to specify its location.CongaRefcan be an actual reference to the namespace or a character array representing the location. For instance:
HttpCommand.CongaRef←#.Utils.Congaor
HttpCommand.CongaRef←'#.Utils.Conga'
This can be useful when integratingHttpCommandinto an application that also uses Conga. HttpCommand.CongaPathcan be used to specify the path to the shared library files and optionally the conga workspace. This can be useful when bundlingHttpCommandin a distributed application. For instance:
HttpCommand.CongaPath←(⊃1 ⎕NPARTS ''),'/conga/'would tellHttpCommandto find the shared libraries in the/conga/subfolder of the current folder. See IntegratingHttpCommandfor more information.
Using Other Versions of Conga
If you need to use a version of Conga other than the one in the Dyalog installation folder, there are two ways to accomplish this:
- Put the shared libraries and the
congaworkspace in a folder and setCongaPathto point to that folder. - Put the
Conganamespace in your workspace (pointingCongaRefto it if necesssary) and the shared libraries in a folder setCongaPathto point to that folder.
Timeout and WaitTime
The operational setting Timeout should not be confused with the Conga setting WaitTime . Internally, after sending the request to the host, HttpCommand sits in a Conga Wait loop, listening for a response. WaitTime is the number of milliseconds that Conga will wait before timing out. When this happens, HttpCommand checks if the request itself has timed out based on the setting of Timeout. If it has, then HttpCommand will stop with a return code of 100 indicating the timeout. If the request has not timed out, then HttpCommand will perform another
iteration of the Conga Wait loop.
It is generally unnecessary to adjust the WaitTime setting. If your request is timing out, increase the Timeout setting.
Note that Timeout is in seconds and WaitTime is in milliseconds.