4.2 Meta-Commands

Meta-commands are instructions to the client engine that can be entered at any data entry prompt. Meta-commands are client plug‑ins that are configured in the properties file. Developers can add their own meta-commands or change the key sequences used to invoke meta-commands. The default configuration, as described in this document, uses a single character prefix followed by a single letter to specify a meta-command, but there is no restriction limiting which characters or how many characters are used to invoke a meta-command. Meta-command key sequences are not case sensitive.

Invocation of a meta-command is recognized whenever the data entry begins with the configured meta-command prefix (wsapi.metacommand.prefix). The default prefix is a forward slash (/). This document uses the default prefix in all meta-command descriptions. (UNIX users might want to change this default to avoid misinterpretation when entering file paths.)

With the exception of the CancelProcessor, all core meta-commands return control to the same prompt and state present when the command was invoked:

4.2.1 Simple Meta-Commands

Simple meta-commands are stateless operations that are always active and always behave in a consistent manner. The base implementation includes simple meta-commands, as listed in Table 4-1.

Table 4-1 Simple Meta-Commands


Default Key Sequence




Lists all current meta-commands with a description and class name for each. Post processor meta-commands (see Section 4.2.2, Post Processor Meta-Commands) can be enabled and disabled, so the listed description changes based on the current state.



Cancels the current activity. From the main menu (or any prompt before the main menu), this command exits the client. For any prompt from the main menu, this command cancels the activity and returns to the main menu.



Plays a recorded script. Refer to Section 4.3, Record/Playback.

4.2.2 Post Processor Meta-Commands

Post processors are used to analyze the results of a Web service invocation. They have a post processor interface that is named after each Web service invocation and a meta-command interface used to enable or disable the post-processors function.

Post processors are invoked in the order they are enabled. If you want to see the SOAP messages before deciding to save them, enable ShowSoapPostProc before enabling SaveSoapPostProc. More information about post processors is available in Section 5.4, MetacommandProcessor and PostProcessor. The base implementation includes the post processor commands listed in Table 4-2.

Table 4-2 Post Processor Meta-Commands


Default Key Sequence




When enabled, displays SOAP request and reply messages.



When enabled, prompts users to save SOAP requests and replies to a file. It can be helpful to use an XML viewer to look the SOAP messages (for example, a Web browser).



When enabled, the cache builder examines the content of SOAP messages for data that can be used to populate options in the UI.

For example, when you select the Update element service from the main menu and the first requested parameter is the DName of the element to update, the UI displays a list of all DNames that were cached from previous queries, allowing the user to select a DName instead of typing one.

Cached data is context sensitive, so when you invoke the nextAlarms service, the UI displays a list of cursors from previous AlarmResultSets and does not display cursors for other types of queries.

Disabling this post processor only stops updates to the cache; it does not disable or remove data already in the cache.



When enabled, this processor first prompts the user for a file name in which it records subsequent SOAP exchanges. All request and reply data is stored in the specified file until the post processor is disabled. Terminating the client prior to disabling the recorder might result in an invalid recording. Refer to Section 4.3, Record/Playback for more information on this feature.