Apply SOAP Commands and WSDL Options

Overview

The Data Management Server supports a number of SOAP commands that enable clients to run jobs and services and administer the server. These Simple Object Access Protocol (SOAP) commands cause the server to return simple types (integers and strings) or types (structures built from simple types and other structures). Definitions of all requests, responses, and complex types are found in the Web Service Definition Language (WSDL) file, in install-path/share.
Note: WSDL 2.0 is not supported.

SOAP Commands Reference

The following table describes the SOAP commands that appear in the WSDL file:
Command
Description
Command Type
GenerateWSDL
Generates a WSDL for a real-time data service or a real-time process service, or for an entire directory including all associated subdirectories. You can pass service names or a single directory name but both cannot be used together in the command. Using a service and directory name together will result in an error. The DataFlux Data Management Server can generate multiple WSDLs within a request and will not stop if an error occurs. To review the responses that result from the use of this command, see Response from the GenerateWSDL Command.
 
GetServerVersion
Returns the server version and the versions of the installed reference data, the repository, and some of the libraries. Also returns date and time elements.
Single version command
ArchitectServiceParam
Returns the input and output fields of a real-time data service.
Data services command
ArchitectService
Runs a real-time data service. The timeout integer element specifies the number of seconds to allow a real-time data service to run before it is stopped by the server. If the timeout element is omitted from the request, or if the value is 0, then the real-time data service will not be stopped by server.
Note: The actual duration of a real-time data service can vary depending on the rounding-up of fractional timeout values. For example, a timeout value of 1.5 is rounded up to an actual duration of 2 seconds.
Data services command
ArchitectServicePreload
Starts the requested number of processes, and loads into those processes the specified real-time data services. For information about preloading services, see Configure the Server to Pre-load Services.
Data services command
ArchitectServiceUnload
Terminates the process that is running the specified real-time data or process service. For further information,
Data services command
LoadedObjectList
Returns a list of running real-time data service processes, along with the name of the loaded service job for each process.
Data services command
MaxNumJobs
Sets the maximum number of concurrent processes that can run real-time data services. This is a run time setting only and has no effect on the value of the configuration option in the dmserver.cfg file. To learn about configuration options, see Configuration Options Reference for dmserver.cfg.
Data services command
WorkFlowJobParams
Returns the inputs and outputs of either a rea-time process service or a batch job.
Process services command
WorkFlowService
Runs a real-time process service.
Process services command
UnloadProcesses
Kills all idle dfwfproc processes and subsequent busy dfwfproc processes once they become idle. The DFWFPROC processes run real-time process services and batch jobs.
Process services command
RunArchitectJob
Runs a batch job.
Batch and profile jobs commands
RunProfileJob
Runs a profile job.
Batch and profile jobs commands
TerminateJob
Terminates a running batch job or profile job. The client can still retrieve the status, log, and statistics file (if one exists) after the job has been terminated.
Batch and profile jobs commands
JobStatus
Returns status information for one or more batch jobs or profile jobs. Applies to jobs that are running or that have already finished.
Batch and profile jobs commands
JobNodesStatus
Returns status information for every node in a batch job. Applies only to the jobs that are currently running.
Batch and profile jobs commands
JobLog
Returns the log file and statistics file (if one exists) for a batch job or profile job. Applies only to already finished jobs.
Batch and profile jobs commands
DeleteJobLog
Deletes the job log, statistics file (if one exists), and all history for a given job run. Applies only to already finished jobs.
Batch and profile jobs commands
ObjectList
Retrieves a list of available objects of a specified type (data services, process services, batch jobs, or profile jobs).
Object files commands
PostObject
Uploads an object of a specified type. If an object of that type with the same name and path already exists, an error is returned.
Object files commands
ObjFile
Downloads an object of a specified type.
Object files commands
DeleteObject
Deletes an existing object of a specified type.
Object files commands
ListAccounts
Returns a list of user and group IDs with explicitly configured server commands permissions (which are included).
Security commands
SetPermissions
Sets server command permissions for a user or group ID.
Security commands
DeleteAccount
Deletes server command permissions for a user or group ID.
Security commands
SetACL
Sets an access control list (ACL) for an object (data service, process service, or batch job).
Security commands
GetACL
Retrieves an ACL for an object.
Security commands

Response from the GenerateWSDL Command

When a client requests the GenerateWSDL command, the response contains two lists:
  1. A list of the job names for which WSDLs were generated successfully.
  2. A list of job names for which WSDLs could not be generated. Each entry in this list includes a detailed error message as to the cause of the problem.
Generating a WSDL is similar to obtaining properties for a service, so the error messages in the job list are similar. Typical messages include the following:
  • job file not found
  • access denied
  • job format is invalid
  • failed to connect to DB
The two job lists are sent only when the request is completed, with or without errors. The amount of time that is required to generate a WSDL is determined by the nature of the job and its dependencies.

Reference for WSDL Configuration Options

The following table describes the configuration options in dmserver.cfg that relate to WSDLs.
Configuration Option
Description
DMSERVER/SOAP/WSDL
Specify a value of YES to load existing WSDLs when you start the DataFlux Data Management Server. Specifying YES also enables the server to recognize other WSDL configuration options and respond to client requests for WSDL-based jobs and services. The default value NO specifies that no existing WSDLs are loaded at start-up, no new WSDLs are generated, client requests to run WSDL-based jobs and services are ignored, and other WSDL configuration options are ignored.
DMSERVER/SOAP/WSDL/GEN
Allows or denies the server the ability to generate run-time WSDLs. Valid option values are NO, SINGLE, or MULTIPLE.
The default value NO specifies that the only WSDLs that can be used to respond to client requests are those that are loaded when you start the Data Management Server. Errors are generated in response to requests to the GenerateWSDL command or the PostObject command.
The value SINGLE enables the generation of a single WSDL for each instance of GenerateWSDL or PostObject.
The value MULTIPLE enables the generation of multiple WSDLs, for SOAP commands that apply to multiple job files or directories of jobs.
Note that WSDL generation can be a time-consuming and resource-intensive process. Also note that erroneous requests to generate multiple WSDLs can cause a severe degradation in server performance.
DMSERVER/SOAP/WSDL/GEN_ON_GET
Allows or denies WSDL generation as part of an HTTP getWSDL request.
The default value NO indicates that an error is returned if the WSDL does not exist, or if the mod.time stamp in the WSDL differs from the mod.time stamp in the service job file. The different mod.time values indicate that the WSDL has been updated on the server, but not on the client.
The value YES indicates that the server does not return an error message if the WSDL does not exist or if the mod.time stamps differ. Instead, the server attempts to generate the latest WSDL. If successful, the server returns the new WSDL to the client.
This option is valid only when the value of DMSERVER/SOAP/WSDL/GEN is SINGLE or MULTIPLE. If the value of DMSERVER/SOAP/WSDL/GEN is NO, then the GEN_ON_GET option is ignored and WSDLs are not generated on HTTP getWSDL requests.
DMSERVER/SOAP/WSDL/RUN_IGNORE_MTIME
When the server receives an HTTP RunSVC request, this option determines whether the client needs to be rebuilt in order to match an updated WSDL. A rebuild is indicated when the mod.time stamp in the WSDL differs from the mod.time stamp in the service job file.
The default value NO specifies not to ignore differences in mod.time values. When the server detects a difference in mod.time values, the server returns to the client the error message Job Has Changed. The client responds by requesting that the server regenerate the WSDL and send the WSDL to the client. The client then rebuilds as directed by the new WSDL.
A value of YES indicates that the server will not compare mod.time values. The server passes the RunSVC request directly to the service process for execution. This behavior applies to service requests that are based on generic WSDL

Debug Real-Time Services Using SOAP Fault Elements and Log Files

When the server encounters an error during the processing of that request, the SOAP response from the server will contain a faultcode tag and a faultstring tag. The faultcode tag categorizes the error. The faultcode tag provides a human-readable description of the error.
The Data Management Server generates the following fault codes:
Error
Description
VersionMismatch
Pertains to the SOAP Envelope element, which is the root element for all SOAP messages. Indicates that the recipient of a message did not recognize the namespace name of the Envelope element.
MustUnderstand
Indicates that the recipient of an element child of the Header element had a soap:mustUnderstand attribute that was not understood by the recipient.
SOAP-ENV:Client
Indicates that the SOAP message did not contain all of the information that is required by the recipient. This could mean that something was missing from inside the Body element. Equally, an expected extension inside the Header element could have been missing. In either case, the sender should not resend the message without correcting the problem.
SOAP-ENV:Server
Indicates that the recipient of the message was unable to process the message because of a server problem. The message contents are not at fault. Instead, a resource was unavailable or process logic failed.
Other fault elements are delivered in the SOAP response, such as the tags faultactor or detail. These elements do not specify a reason for the fault or indicate the data element that triggered the error. These tags are generic in nature and are usually returned for any and all SOAP requests. Because the DataFlux Data Management Server logs information related to processing errors, these optional SOAP elements are not used for error messaging. It is necessary to look at a log file to obtain details for problem determination. Depending on the nature of the problem, the error might be exposed in a server log or specific service process log. To learn more about logs, see Administer DataFlux Data Management Server Log Files and see Administer Data Service Log Files..
Also note that the nil tags are unused for SOAP fault messaging. It is best not to refer to these elements for problem determination.