Hyrax - BES Client commands: Difference between revisions

From OPeNDAP Documentation
⧼opendap2-jumptonavigation⧽
No edit summary
Line 1: Line 1:
= Client commands =
These are the commands that the BES supports. Documented here are the XML versions of the commands that are typed into the ''bescmdln'' client. All of these have a non-XML version as well that might be easier to type as the command line. However, if you're making command files, these are often the easiest to use because the SQL-like syntax of the 'text' commands can be confusing.


If you want to find documentation on the XML document that the BES expects to receive, look at the [[BES XML Commands]] documentation. There you'll see that the commands listed here are generally sent as given to the ''bescmdln'' client but embedded in other XML that provides the BES with information such as a request ID and other bookkeeping information.
== Current core commands available with BES ==
== Current core commands available with BES ==


Line 80: Line 81:
* <setContext name="errors">dap2|xml|html|txt</setContext>
* <setContext name="errors">dap2|xml|html|txt</setContext>
:* set the context 'errors' to dap2 in order to have all exceptions and errors formatted as dap2 error messages in the response.
:* set the context 'errors' to dap2 in order to have all exceptions and errors formatted as dap2 error messages in the response.
== '''[[BES_XML_Commands | More Details Here]]''' ==

Revision as of 17:49, 3 December 2009

These are the commands that the BES supports. Documented here are the XML versions of the commands that are typed into the bescmdln client. All of these have a non-XML version as well that might be easier to type as the command line. However, if you're making command files, these are often the easiest to use because the SQL-like syntax of the 'text' commands can be confusing.

If you want to find documentation on the XML document that the BES expects to receive, look at the BES XML Commands documentation. There you'll see that the commands listed here are generally sent as given to the bescmdln client but embedded in other XML that provides the BES with information such as a request ID and other bookkeeping information.

Current core commands available with BES

  • <showHelp />
  • shows this help
  • <showVersion />
  • shows the version of OPeNDAP and each data type served by this server
  • <showProcess />
  • shows the process number of this application. This command is only available in developer mode.
  • <showConfig />
  • shows all key/value pairs defined in the bes configuration file. This command is only available in developer mode.
  • <showStatus />
  • shows the status of the server
  • <showContainers />
  • shows all containers currently defined
  • <showDefinitions />
  • shows all definitions currently defined
  • <showContext />
  • shows all context name/value pairs set in the BES
  • <setContainer name="container_name" space="store_name" type="data_type">real_name</setContainer>
  • defines a symbolic name representing a data container, usually a file, to be used by definitions, described below
  • the space property is the name of the container storage and is optional. Defaults to default volatile storage. Examples might include database storage, volatile storage based on catalog information.
  • real_name is the full qualified location of the data container, for example the full path to a data file.
  • data_type is the type of data that is in the dataset. For netcdf files it is nc. For some container storage the data type is optional, determined by the container storage.
  • <setContext name="context_name">context_value</setContext>
  • set the given context with the given value. No default context are used in the BES
  • <define ...>
<define name="definition_name" space="store_name">
    <container name="container_name">
        <constraint>legal_constraint</constraint>
        <attributes>attribute_list</attributes>
    </container>
    <aggregate handler="someHandler" cmd="someCommand" />
</define>
  • creates a definition using one or more containers, constraints for each of the containers, attributes to be retrieved from each container, and an aggregation. Constraints, attributes, and aggregation are all optional.
  • There can be more than one container element
  • space is the name of the definition storage. Defaults to volatile storage. Examples might include database storage.
  • <deleteContainer name="container_name" space="store_name" />
  • deletes the specified container from the specified container storage (defaults to volatile storage).
  • <deleteContainers space="store_name" />
  • deletes all of the currently defined containers from the specified container storage (defaults to volatile storage).
  • <deleteDefinition name="definition_name" space="store_name" />
  • deletes the specified definition from the specified container storage (defaults to volatile storage).
  • <deleteDefinitions space="store_name" />
  • deletes all of the currently defined definitions from the specified container storage (defaults to volatile storage).

Added commands for dap enabled servers

If you are serving up OPeNDAP data responses (DAS, DDS, DataDDS) then you will have loaded the dap commands in your configuration file. Here are the available commands in the dap module.


  • <showCatalog node="node_name" />
  • Shows catalog information, including contents if a container. If node is not specified then the root node information is returned. If node is specified then that nodes information is returned.
  • <showInfo node="node_name" />
  • Shows catalog information for just that node, the root node if no node is specified. If the node is a container the contents are not displayed.
  • <get type="das|dds|dods|ddx|dataddx" definition="def_name" returnAs="returnAs" />
  • dds: request the data descriptor structure. Returned as text.
  • das: request the data attributes. Returned as text.
  • dods: request for the data stream, this output is an octet binary stream made up of two parts and similar to a multipart MIME document (but not a real MPM doc). The first part is the DDS that describes the contents of this response; the separator is the text Data:; and the data make up the third part. The data are represented using XDR-encoded binary values. There is a a one-to-one mapping between variables, name and types in the first part and the binary values in the second part. A library such as libdap can easily decode this response.
  • ddx: request the data attributes and data descriptor structure returned as an xml document
  • dataddx: This is the 'DAP4' counterpart to the dods response, just as the ddx is the DAP4 counterpart to the das and dds responses from DAP2. The dataddx response is a true multipart MIME document with the first part a text/xml section that holds the ddx that describes the data in the response and the second part an application/octet-stream section that holds the matching XDR-encoded values.
  • <setContext name="errors">dap2|xml|html|txt</setContext>
  • set the context 'errors' to dap2 in order to have all exceptions and errors formatted as dap2 error messages in the response.