The Oracle SALT Command Reference describes system processes and commands delivered with the Oracle SALT software.
Table 1 lists Oracle SALT commands and functions.
buildscaclient
– Builds processes that call SCA components.
buildscaclient -c defaultcomponent[-v] [-k] [-o name]
[-s scaroot][-f firstfiles] [-l lastfiles]
This command is used to build client processes that can call SCA components hosted in Tuxedo environments. The command combines files, specified using the -f and -l options, with the SCA and standard Tuxedo ATMI libraries to form a client application. The client application is built using the default C++ language compile command defined for the operating system in use, unless overridden using the CC
environment variable.
All specified .c
and .cpp
files are compiled in one invocation of the compilation system based on the operating system. Users may specify the compiler to invoke by setting the CC environment variable to the name of the compiler. If the CC
environment variable is not defined when buildscaclient
is invoked, the default C++ language compile command for the operating system is invoked to compile all .c
and .cpp
files.
You may specify additional options to be passed to the compiler by setting the CFLAGS
or the CPPFLAGS
environment variables. If CFLAGS
is not defined when buildobjclient
is invoked, then buildscaclient
uses the value of CPPFLAGS
, if that variable is defined.
buildscaclient supports the following parameters and options:
-c defaultcomponent
[-v]
buildscaclient
command should work in verbose mode. In particular, it writes the compile command to its standard output.
[-k]
buildscaclient
generates proxy files that allow dynamic interfacing of clients and references. This is normally compiled and then removed when the proxy is built. This option indicates that the source file should be retained.
Caution: | The generated contents of this file may change from release to release. It is advised that you do not depend on the data structures and interfaces exposed in this file. This option is provided to aid in debugging of build problems. |
[-o name]
client<.type>
, where type is an extension that is dependent on the operating system. For example, on a UNIX system, there would not be a type, but on a Windows system, the type would be .EXE
.
[-s scaroot]
APPDIR
environment value is used.
[-f firstfiles]
buildscaclient
command. The specified file is included before the SCA libraries are included. There are two ways of specifying a file or files:
Note: |
[-l lastfiles]
buildscaclient
command. The specified file is included after the SCA libraries are included. There are two ways of specifying the file, as shown in the following table.
Note: |
Following is a list of environment variables for buildSCAclient
:
TUXDIR
CC
.c
or .cpp
file extensions. If not defined, the default C++ language compile command is invoked to compile all .c
and .cpp
files, based on the operating system.
CFLAGS
.c
or .cpp
file extensions. If CFLAGS
does not exist in the buildscaclient
command environment, the command checks for the CPPFLAGS
environment variable.
Note: | Arguments passed by the CFLAGS environment variable take priority over the CPPFLAGS variable. |
CPPFLAGS
.c
or .cpp
file extensions.
"-I$(TUXDIR)/include"
for UNIX systems or the command line option /I%TUXDIR%\include
for Windows systems, which is passed automatically by the buildscaclient
command. If CPPFLAGS
does not exist in the buildscaclient
command environment, no compiler commands are added.
LD_LIBRARY_PATH (UNIX systems)
LIB (Windows systems)
This command is available on any platform on which the Oracle SALT environment is supported.
buildscaclient -s /myApplication/scaSrc/uBike
-c SearchRedBikes
buildscaserver(1), buildscacomponent(1)
buildscacomponent
- builds SCA components
buildscacomponent [-v] [-s scaroot] [-f firstfiles] [-l lastfiles] -c compositename[/componentname][,compositename,..]] [-y] [-k] [-h]
buildscacomponent
is used to build individual SCA components from source code. The command reads SCDL source, finds the component(s) in the composite(s) file(s) specified, parses the corresponding .componentType file(s) and produces corresponding executable libraries, in the same location as the .componentType files.
The command automatically builds component implementations based on the contents of <implementation.cpp>
elements as follows:
/implementation.cpp/@header
is used to determine the name of the source and componentType
files containing the implementation.For example, an element such as
<implementation.cpp library="myLib" header="myComponentImpl.h"/>
causes buildscacomponent
to look for a myComponentImpl.cpp file and compile it, along with stubs generated from its interface located in a corresponding myComponentImpl.componentType file.
Composites may contain one or more components, and the buildscacomponent
command may build one or more composites in one pass. If more than one component is built, the files specified using the -f
and -l
switches are included in each component. To build a single component, the -c composite/component
syntax should be used. This addresses the cases where individual components are made up of specific sets of source code or libraries.
All specified .c
and .cpp
files are compiled in one invocation of the compilation system for the operating system in use. Users may specify the compiler to be invoked by setting the CC
environment variable to the name of the compiler. If the CC
environment variable is not defined when buildscacomponent
is invoked, the default C++ language compile command for the operating system in use is invoked to compile all .c
and .cpp
files.
Users may specify options to be passed to the compiler by setting the CFLAGS
or the CPPFLAGS
environment variable. If CFLAGS
is not defined but CPPFLAGS
is defined when buildscacomponent
is invoked, the CPPFLAGS
value is used.
buildscacomponent
supports the following parameters and options:
[-v]
[-s scaroot]
[-f firstfiles]
buildscacomponent
command. The specified file is included before the SCA libraries are included. There are two ways of specifying a file or files, as shown in Table 2.
Note: | Filenames that include spaces are not supported. The -f option may be specified multiple times. |
[-l lastfiles]
buildscacomponent
command. The specified file is included after the SCA libraries are included. There are two ways of specifying a file, as shown in Table 3.
Note: | Filenames that include spaces are not supported. The -l option may be specified multiple times. |
-c {composite[,composite]|composite/component}
APPDIR
or in the SCDL directory specified above with the -s switch. If it cannot be found, the component libraries are not built.
-f
and -l
need to be included in the build process of a component.
[-y]
-c
switch but not physically present from the root directory.
[-k]
buildscacomponent
generates proxy and wrapper code with data structures such as the method operation and parameter handling. This is normally compiled and then removed when the component is built. This option indicates that the source file should be kept (to see what the source filename is, use the -v
option).
Note: | The generated contents of this file may change from release to release; DO NOT count on the data structures and interfaces exposed in this file. This option is provided to aid in debugging of build problems. |
TUXDIR
APPDIR
CC
.c
or .cpp
file extensions. If not defined, the default C++ language compile command for the operating system in use will be invoked to compile all .c
and .cpp
files.
CFLAGS
.c
or .cpp
file extensions. If CFLAGS
does not exist in the buildscacomponent
command environment, the buildscacomponent
command checks for the CPPFLAGS
environment variable.
CPPFLAGS
Note: | Arguments passed by the CFLAGS environment variable take priority over the CPPFLAGS variable. |
.c
or .cpp
file extensions.
This is in addition to the command line option -I$(TUXDIR)/include
for UNIX systems or the command line option /I%TUXDIR%\include
for Windows systems, which is passed automatically by the buildscacomponent
command. If CPPFLAGS
does not exist in the buildscacomponent
command environment, no compiler commands are added.
LD_LIBRARY_PATH (UNIX systems)
SHLIB_PATH
environment variable; for AIX, use LIBPATH
.
LIB (Windows systems)
buildscacomponent
is supported on any platform on which the Oracle SALT environment is supported.
buildscacomponent -f utils.c -c searchInventory,updateItem
buildscaserver
– Builds a Tuxedo server containing SCA component.
-o servername -c composite[,composite][-v][-s scaroot]
[-w] [-r rmname][-y] [-k] [-t]
buildscaserver
is used to build a Tuxedo server that is used to route requests to SCA components previously built with the buildscacomponent command. The command generates a main routine that contains bootstrap routines to route Tuxedo or SCA requests to SCA components, and compiles it to form a server host application. The server host application is built using the default C++ compiler provided for the platform.
If the scdl code contains references or services with <binding.ws>
elements, these will automatically be converted into WSDF files for use by the Web Services gateway (GWWS). All SCA servers built using buildscaserver
are multi-threaded servers.
buildscaserver
supports the following parameters and options:
-o servername
-c compositename[,compositename]
APPDIR
, or in the SCDL directory specified above with the -s
switch. If it is not found, the server is not built. In case you specify a list of composites, then all the listed composites are hosted by the same Tuxedo server.
incorrect name
or composite does not have any atmi service binding
, a warning message is displayed and the user is prompted to confirm whether the command should continue processing or abort.
[-v]
[-s scaroot]
[-w]
buildscacomponent
command).
[-r rmname]
rmname
must appear in the resource manager table located in $TUXDIR/udataobj/RM
on UNIX systems or %TUXDIR%\udataobj\RM
on Windows systems. Each entry in this file is of the following form:
rmname:rmstructure_name:library_names
Using the rmname
value, the entry in $TUXDIR/udataobj/RM
or %TUXDIR%\udataobj\RM
automatically includes the associated libraries for the resource manager and sets up the interface between the transaction manager and the resource manager. The value TUXEDO/SQL
includes the libraries for the Oracle Tuxedo System/SQL resource manager. Other values can be specified once they are added to the resource manager table. If the -r
option is not specified, the null resource manager is used, by default.
[-y]
[-k]
buildscaserver
generates a main stub with data structures such as the service table and a main()
function. This is normally compiled and then removed when the server is built. This option indicates that the source file should be retained.
Note: | To see the source filename, use the -v option. |
Caution: | The generated contents of this file may change from release to release. It is advised that you do not depend on the data structures and interfaces exposed in this file. This option is provided to aid in debugging build problems. |
[-t]
TUXDIR
CC
.c
or .cpp
file extensions. If not defined, the default C++ language compile command is invoked to compile all .c
and .cpp
files.
CFLAGS
.c
or .cpp
file extensions. If CFLAGS
does not exist in the buildscaserver
command environment, the buildscaserver
command checks for the CPPFLAGS
environment variable.
Note: | Arguments passed by the CFLAGS environment variable take priority over the CPPFLAGS variable. |
CPPFLAGS
.c
or .cpp
file extensions.
"-I$(TUXDIR)/include"
for UNIX systems or the command line option /I%TUXDIR%\include
for Windows systems, which is passed automatically by the buildscaserver
command. If CPPFLAGS does not exist in the buildscaserver
command environment, no compiler commands are added.
LD_LIBRARY_PATH (UNIX systems)
(:)
is used to separate the list of directories. Some UNIX systems require different environment variables:
LIB (Windows only)
(;)
is used to separate the list of directories.
This command is available on any platform on which the Oracle SALT server environment is supported.
buildscaserver -o uBikeServer -f utils.c
-d /myApplication/myModules/uBike
-s /myApplication/uBikeComponents/uBike
This command checks for the following inconsistencies in the SCDL code and reports error messages if:
<remoteAccess>
elements. <remoteAccess>
elements with a value of WorkStation are not supported by this command./binding.atmi/@requires
contains a legacy value and /binding.atmi/map
elements contain values that conflict (for example, the same Tuxedo service name mapped to two or more different methods)
GWWS(5)
, buildscacomponents(1)
GWWS
– Web service gateway server.
GWWS SRVGRP="identifier" SRVID=number [other_parms]
CLOPT="-A -- – i InstanceID"
The GWWS server is the Web service gateway for Tuxedo applications, the core component of Oracle SALT. The GWWS gateway server provides communication with Web service programs via SOAP 1.1/1.2 protocols. The GWWS server has bi-directional (inbound/outbound) capability. It can accept SOAP requests from Web service applications and passes Tuxedo native calls to Tuxedo services (inbound). It also accepts Tuxedo ATMI requests and passes SOAP calls to Web service applications (outbound). GWWS
servers are used as Tuxedo system processes and are described in the *SERVERS
section of the
UBBCONFIG file.
The CLOPT
option is a string of command-line options passed to the GWWS
server when it is booted. The GWWS
server accepts the following CLOPT
options:
-i InstanceID
GWWS
instance unique ID. It is used to distinguish multiple GWWS
instances provided in the same Tuxedo domain. This value must be unique among multiple GWWS
items within the UBBCONFIG
file.
Note: | The InstanceID value must be pre-defined in the <WSGateway> section of the Oracle SALT Deployment File. |
The SALTCONFIG
environment variable must be set before the GWWS server is booted.
Accesslog(5)
can be enabled by setting environment variable TMENABLEALOG=y
.
The following SALT 1.1 GWWS parameter is deprecated in the current release.
-c Config_file
Note: | Starting with the SALT 2.0 release, the GWWS server loads the SALT configuration from the binary SALTCONFIG file instead of the XML-based configuration file. The configuration file is no longer a GWWS server input parameter. The SALTCONFIG file must be generated using wsloadcf before booting GWWS servers. |
For inbound call, if an error occurs during SOAP message processing, the error is logged. The error is also translated into appropriate SOAP fault and/or HTTP error status code and returned to the Web service client.
For outbound call, if an error occurs during processing, the error is logged. The error is also translated into appropriate Tuxedo system error code (tperrno
) and returned to the Tuxedo client.
*SERVERS
GWWS SRVGRP=GROUP1 SRVID=10
CLOPT="-A -- – i GW1"
GWWS SRVGRP=GROUP1 SRVID=11
CLOPT="-A -- – i GW2"
GWWS SRVGRP=GROUP2 SRVID=20
CLOPT="-A -- – i GW3"
SALT Deployment File Reference
SALT Web Service Definition File Reference
The mkfldfromschema
and mkfld32fromschema
commands take an XML schema as input and produce a field table. This table can be processed by the mkfldhdr
or mkfldhdr32
command or is loaded by programs that need it. mkfldfromschema
is used with 16-bit FML and mlfld32fromschema
is used with 32-bit FML.
These commands have the following restrictions:
mkfldfromschema, mkfld32fromschema
– Generates field table from an XML schema
mkfldfromschema{-i schema|-u schemaurl} -b basenumber -o
mkfld32fromschema
outputfile{-i schema|-u schemaurl} -b basenumber -o
outputfile
These commands take an XML schema as input and generate a field table. The XML schema may be specified using either the -i
option or the -u
option. If neither option is specified, the schema is read from standard input.
mkfldfromschema
and mkfld32fromschema
supports the following options:
-b basenumber
-i schema
-i
option cannot be specified in conjunction with the -u
option.
-u schemaurl
-u
option cannot be specified in conjunction with the -i
option.
-o outputfile
These commands are available on any platform that supports the Oracle Tuxedo server environment.
mkviewfromschema, mkview32fromschema
The mkviewfromschema
and mkview32fromschema
commands take an XML schema as input and produce a view file. This file can be processed by the viewc
or viewc32
command. mkviewfromschema
is used with 16-bit views and mkview32fromschema
is used with 32-bit views.
mkviewfromschema, mkview32fromschema
– Generates view table from an XML schema
mkviewfromschema {-i schema|-u schemaurl} -o outputfile
mkview32fromschema {-i schema|-u schemaurl} -o outputfile
These commands take an XML schema as input and generate a view file. The XML schema may be specified using either the -i
option or the -u
option. If neither option is specified, the schema is read from standard input.
mkviewfromschema
, mkview32fromschema
supports the following options:
-i schema
-i
option cannot be specified in conjunction with the -u
option.
-u schemaurl
-u
option cannot be specified in conjunction with the -i option.
-o outputfile
These commands are available on any platform that supports the Oracle Tuxedo server environment.
mkfldfromschema, mkfld32fromschema
SDO for C++ Specification V2.1published December, 2006
scaadmin
– SCA server management command interpreter
scaadmin [-v]
Use the scaadmin
command to dynamically redeploy SCA composites or display statistics and status of individual services. The TUXCONFIG
environment variable is used to determine the location where the Tuxedo configuration file is loaded.
This command has no effect on servers that have not been built using the buildscaserver(1)
command.
The scaadmin
command supports the following option:
[-v ]
scaadmin
to display the Oracle SALT version number, SALT Patch Level. The command exits after print out.
default [-m machine] [-g groupename] [-i srvid] ] [-s servername]
reload [-m machine] [-g groupname] [-i srvid] ] [-s servername]
-m
, -g
, -i
and -s
options can be used to restrict the reloaded servers to any combination of machine, group, server id and server name.
printstats [-m machine] [-g groupname] [-i srvid] [-s servername]
active
, idle
). The -m
, -g
, -i
and -s
options can be used to restrict the reloaded servers to any combination of machine, group, server id and server name.
verbose (v) [{off | on}]
off
.
help (h) [{command | all}]
echo (e) [{off | on}]
off
.
quit (q)
The scaadmin
command must run on an active node.
scaadmin
is supported on any platform that supports the Oracle SALT server environment.
The following command reloads all the composites hosted by the uBikeServer
Tuxedo application server, which was built using the buildscaserver(1)
command.
The following command displays statistics on the services offered by the uBikerServer
Tuxedo application server, which was built using the buildscaserver(1)
command.
scaadmin
> printstats -s uBikeServer
Service Method Status Requests
Processed
SEARCHINVENTORY searchInventory A 37
scapasswordtool
– Manages passwords for Tuxedo authentication in SCA clients.
scapasswordstore -i passwordidentifier -[a|d]
This command manages the password.store
file used by SCA components to refer to Tuxedo-based services.
Passwords are prompted and encrypted. The encrypted version is stored in this file, associated with a clear-text identifier. This command is also used to delete identifier/password pairs from the file.
The password is limited to 40 characters. If standard input is not a terminal, that is, if the user cannot be prompted for a password (as with a Here file, for example), then the APP_PW
environment variable is accessed to set the password. If the APP_PW
environment variable is not set and standard input is not a terminal, then scapasswordtool
prints an error message and exits.
A password.store
file is created in the current directory if it does not previously exist.
-i passwordidentifier
<binding>
element. SCA components search the password for this element.
-[a|d]
-a
option adds an identifier/password pair, whereas the -d
option deletes it. An error message is printed out and the command processing is aborted in one of the following situations:
This command is available on any platform that supports the Oracle Tuxedo server environment.
setSCAPasswordCallback()
– Sets the callback for retrieving a password associated with an identifier in a <binding.atmi>
element.
#include <tuxsca.h>
void setSCAPasswordCallback(char * (_TMDLLENTRY *)(*disp) (char
*identifier))
setSCAPasswordCallback()
allows an SCA component to identify the callback that returns the clear-text password that is passed to the appropriate authentication code.
The function pointer passed on the call to setSCAPasswordCallback()
must conform to the specified parameter definition. The _TMDLLENTRY
macro is required for Windows-based operating systems to obtain the proper calling conventions between the Tuxedo libraries and your code. On UNIX systems, the _TMDLLENTRY
macro is not required because it expands to the null string.
The identifier points to the password identifier passed to the callback function. The callback function then returns a char *
that points to the actual clear-text password.
The setSCAPasswordCallback()
function does not return any data.
On failure, setSCAPasswordCallback()
sets tperrno
to one of the following values:
[TPEPROTO]
[TPESYSTEM]
TPEOS
]
tmscd(1)
– Activates and deactivates service contract discovery.
tmscd start|stop|status [-e] [-f <file>][id1 [ id2 [ ...]]]
The
tmscd
command line utility is used to activate and deactivate service contract discovery.
tmscd accepts following parameters and options:
start|stop|status
start
or stop
request for a service that has already activated or deactivated contract discovery is ignored. Effective service information is displayed when handling the requests.
Note: | start|stop|status must occur after -e and -f , if either of those options are specified. |
[-e]
[-f <file>]
<file>
. The file may contain sections to group related definitions together. All entries for a section must be written together line-by-line.
"id=content"
definitions.
id1 id2 ...
-e
is specified, a regular expression is used to match the service name. If -e
is not specified, the service name is matched exactly.
Example 1 - start discovery for TOUPPER
, TOLOWER
:
tmscd start TOUPPER TOLOWER
Example 2 - start discovery for services started with TO
and BR
:
tmscd -e start TO.* BR.*
Example 3 - same request as example 1 but via file:
tmscd -f svcfile start id1 id2
Note: | The first found definition is used if section is not provided: |
Example 4 - same request as example 2 but via file:
tmscd -e -f svcfile start case4.svcs
Listing 2 shows content of the file named "svcfile
".
# file: svcfile
*case3
id1 = TOUPPER
id2 = TOLOWER
*case4
svcs = TO.*|BR.*
tmscd
fails if TMMETADATA is not booted or booted using the -r
(readonly) option without the -o
option.
Configuring Service Contract Discovery in the Oracle SALT Administration Guide
tmwsdlgen
– WSDL document generator.
tmwsdlgen – c wsdf_file [-y] [-o wsdl_file] [-m {pack|raw|mtom}] [-t
{wls|axis}]
tmwsdlgen
generates a WSDL document file from a Tuxedo native Web Service Definition File (WSDF). The generated WSDL document is WSDL 1.1 specification compliant, and represents both the service contracts and policies. tmwsdlgen
collects Tuxedo service contract information throughout the Tuxedo Service Metadata Repository management (TMMETADATA)process. tmwsdlgen
works as a Tuxedo native client and requires the following:
WARNING: | The given WSDF must be a Tuxedo native WSDF. Do not use a wsdlcvt converted non-native WSDF file as input. |
tmwsdlgen
accepts the following parameters:
-c wsdf_file
tmwsdlgen
accepts the following optional parameters:
-o wsdl_file
tuxedo.wsdl
, is created in the current directory. If the specified WSDL document file already exists, then a prompt displays to confirm to overwriting the existing file.
-y
-m
raw
mode is specified, CARRAY is represented to the MIME attachment. If pack
mode is specified, xsd:base64Binary
is used to represent CARRAY. The default value is pack
mode.
Note: | raw mode cannot be used for .Net clients. The .Net Framework does not support MIME attachments. |
-t
-m
option is specified in raw
mode. It accepts two options, wls
or axis
:
The following SALT 1.1 tmwsdlgen parameters are deprecated in the current release.
-c Config_file
Note: | In the current SALT release, the SALT 1.1 configuration file is specified as the tmwsdlgen input using the following optional parameters: |
-s
-v
Note: | In the current SALT release, the SOAP version and message style attribute are specified in the Oracle SALT WSDF. |
If a syntax error is detected in the given WSDF, an “ERROR” or “FATAL” message indicating that problem is printed to the standard error, and no WSDL file is generated and tmwsdlgen
exits with exit code 1.
A “WARN” message is printed to the console if:
Upon successful completion, tmwsdlgen
exits with exit code 0.
The following command generates a WSDL document file, Salt.wsdl, from the specified SALT WSDF, tux.wsdf
.
tmwsdlgen – c tux.wsdf – o Salt.wsdl
The following command generates a default WSDL document file with SOAP w/Attachment capability from the specified SALT WSDF, app_wsdf.xml
.
tmwsdlgen – c app_wsdf.xml – m raw
SALT Web Service Definition File Reference
tuxscagen
– Generates SCA, SCDL, and server side interface files for Tuxedo services.
tuxscagen [-s <target-root-directory>][-d <service-name>]
[-C <TUXEDO_cltname>][-u <TUXEDO_username>][-j <java_package_name>]
[-o <output_SCDL_filename>][-i <output_interface_filename>]
[-m <max-intf-arguments>] [-y][-v][-h] [-F] [-c][-g i|a|s]
[-trepository=<filename> | -tinfile=<metarepos.infile> | -tmetadata]
This tool is used to generate interface and SCDL files. The interface files are used for developing the SCA component using ATMI binding, or wrap existing Tuxedo services in an SCA component. The SCDL files are assembly artifacts that help SCA run time to locate the module and services.
tuxscagen supports the following options:
-s target-root-directory
-d<service-name>
-C <TUXEDO_cltname>
-u <TUXEDO_username>
username
as the user name when joining the Tuxedo application. This is required when Tuxedo security level is higher than APP_PW
and input method is to retrieve Tuxedo Service Metadata from TUXEDO.TMMETAREPOS
Service.
-j <java_package_name>
tuxscagen
generates C++ header files. If -g
is not specified but if -j <java_package_name>
is specified then -ga
is assumed. However, if -g
sub-option i
or s
is specified, a warning message is displayed.
-o <output_SCDL_filename>
componentType
file. If this option is not specified, then by default, one composite and one componentType
are generated for each Tuxedo service. However, if this option is specified with the output filename, only one composite and one componentType
file is generated for all the matching Tuxedo services. If the specified <output_SCDL_filename>
already exists, an interactive prompt is displayed and requires user input (unless -y
is specified). If this option is specified, -F
is automatically implied.
-i <output_interface_filename>
<output_interface_filename>
already exists, an interactive prompt is displayed and requires user input (unless -y
is specified).
If this option is specified, -F
is automatically implied.
-m <max-intf-arguments>
commonj::sdo::DataObjectPtr
.
-m
is not specified, the default threshold is 10.
If 0
specified, it will always generate using commonj::sdo::DataObjectPtr
.
If -ga
is not specified, this option is ignored.
-y
Really overwrite files:<filename> [y, q]
?
so that the script can run without user input. This question appears if either or both -o
and -i
are specified. If both these options are not specified, by default existing files are replaced.
-v
-h
-F
Flat File
view. If this option is specified, then all the generated files are put in the target root directory. The default is Tree File
view.
tuxscagen
generates server-side SCDL, specifying this option changes it to generate client-side SCDL.
-g a|i|s
a
sub-option is used to generate abstract base class header files. The sub-option i
is to generate implementation class header files. Sub-option s
is used to generate SCDL files. To generate both header files, specify -gai
. To generate all files, specify -gais
.
[-trepository=<filename> | -tinfile=<metarepos.infile> | -tmetadata]
-trepository=<filename>
is specified, tuxscagen
retrieves service parameter information from the Service Metadata repository file <filename>.
If -tinfile=<metarepos.infile>
is specified, then tuxscagen
retrieves service parameter information from <metarepos.infile>
, where the <metarepos.infile>
syntax is suitable for input to tmloadrepos
. If -tmetadata
is specified, tuxscagen
retrieves service parameter information from the Tuxedo TMMETADATA server.
At most, one -t
option can be specified; the default is -tmetadata
.
This tool is available on ny platform on which the Oracle SALT environment is supported.
The following command is used to generate SCDL, interface, and implementation header files from a Tuxedo Metadata Repository file named myrepository
in the current working directory. The number of interface method input arguments is limited to 8. If the limit is exceeded, the XSD schema file is still generated.
tuxscagen -s /home/tux/sca -Dname=TRANSFER -gais -m 8 -trepository=myrepository
tmloadrepos(1), tmunloadrepos(1)
Managing The Tuxedo Service Metadata Repository in Setting up a BEA Tuxedo Application.
wsadmin
– Oracle SALT administration command interpreter.
wsadmin [-v]
wsadmin
uses specific commands to monitor and administrate active GWWS processes in the specified Tuxedo domain. The TUXCONFIG environment variable is used to determine the location where the Tuxedo configuration file is loaded. wsadmin is used in the same manner as tmadmin(1) or dmadmin(1).
wsadmin
accepts below optional parameter:
-v
wsadmin
exits after print out.
Commands may be entered using either their full name or their abbreviation (as given in parentheses), followed by any appropriate arguments. Arguments appearing in brackets, [ ], are optional; arguments in braces, {}, indicate a selection from mutually exclusive options.
Note: | Command line options that are not in brackets do not need to appear in the command line if the corresponding default has been set via the default command. |
wsadmin
supports the following commands:
configstats(cstat) -i gwws_instance_id
default(d) [-i gwws_instance_id]
echo(e) [{off | on}]
help (h) [command]
gwstats(gws) -i gwws_instance_id [-s serviceName]
serviceName
specified, the server-level information is displayed.
paginate(page) [{off | on}]
pg
. The shell environment variable PAGER may be used to override the default command used for paging output
quit (q)
verbose (v) [{off | on}]
! shellcommand
! !
# [text]
<CR>
wsadmin
> gws -i GW2GWWS Instance : GW2
Inboud Statistics :
---------------------------------
Request Response Succ : 3359
Request Response Fail : 0
Oneway Succ : 0
Oneway Fail : 0
Total Succ : 3359
Total Fail : 0
Avg. Processing Time : 192.746 (ms)
---------------------------------
Outboud Statistics :
---------------------------------
Request Response Succ : 4129
Request Response Fail : 0
Oneway Succ : 0
Oneway Fail : 0
Total Succ : 4129
Total Fail : 0
Avg. Processing Time : 546.497 (ms)
-----------------------------------
Total request Pending : 36
Outbound request Pending : 0
Active Thread Number : 141
The following command inspects run time statistics for theToUpperWS
service on GW1 and gets output in verbose mode.
wsadmin
> > verbose
Verbose now on.
> gws -i GW1 -s ToUpperWS
GWWS Instance : GW1
Service : ToUpperWS
Outboud Statistics :
----------------------------------
Oneway Succ : 0
Oneway Fail : 0
---------------------------------
Avg. Processing Time : 0.000 (ms)
wsdlcvt
– WSDL document converter.
wsdlcvt -i WSDL_URL -o output_basename [-m] [-v] [-y] [-w]
wsdlcvt is used to convert an existing WSDL 1.1 document to a Metadata Input File, FML32 mapping File and Oracle SALT Web Service Definition File (WSDF). It is a wrapper script for wsdl2mif.xsl
, wsdl2fml32*.xsl
and wsdl2wsdf.xsl
for Xalan. Apache Xalan 2.7 libraries are bundled with Oracle SALT product.
JRE 1.5 or higher is required to run wsdlcvt
.
wsdlcvt
accepts the following parameters:
-i
-o
wsdlcvt
accepts the following optional parameters:
-y
-m
-v
wsdlcvt
works in verbose mode. In particular, it shows context information in the message and output context as FML32 field comments.
-w
wsdlcvt
can handle it correctly.
The TUXDIR and LANG environment variables must be set correctly.
The PATH
environment variable must be set appropriately to execute “java”.
Error, warning or information messages are output to standard output.
The following command converts the local WSDL file, sample.wsdl
.
wsdlcvt -i sample.wsdl -o sample
The following command converts a WSDL document from a HTTP URL link. The “xsd:string” data type is mapped to the Tuxedo FLD_MBSTRING field type.
wsdlcvt -i http://api.google.com/GoogleSearch.wsdl -o GSearch -m
Creating The Tuxedo Service Metadata Repository
SALT Web Service Definition File Reference
wsloadcf
– Reads SALT Deployment file and other referenced artifacts. Loads a binary SALTCONFIG file.
Usage 1: wsloadcf [-n][-y][-D loglevel] saltdeploy_file
Usage 2: wsloadcf [-n][-y][-D loglevel] -1 [-s rpc|doc]
[-v 1.1|1.2] salt_1.1_config
wsloadcf reads a SALT deployment file and other referenced files (WSDF files, WS-Policy files), checks the syntax, and optionally loads a binary SALTCONFIG
file. The SALTCONFIG
environment variable points to the SALTCONFIG
file where the information should be stored. The generated SALTCONFIG file is necessary to boot GWWS
servers.
wsloadcf accepts the following optional parameters:
-n
-y
tmloadcf
checks whether: (a) the file referenced by SALTCONFIG
exists; (b) it is a valid Oracle Tuxedo system file system; and (c) it contains SALTCONFIG
tables. If these conditions are not true, wsloadcf
prompts you to indicate whether you want the command to create and initialize SALTCONFIG
.
Initialize SALTCONFIG file: path [y, q]?
Prompting is suppressed if the -y option is specified on the command line.
-D
For SALT 1.1 backward compatibility, wsloadcf can also read a SALT 1.1 configuration file. Besides generating the SALTCONFIG binary file, wsloadcf
also generates one SALT Web Service Definition File (WSDF) and one SALT Deployment file according to the given SALT 1.1 configuration file.
-1
wsloadcf
, you must specify this flag first.
The SALTCONFIG environment variable must be set before executing wsloadcf.
If a syntax error is detected in the given configuration files, an “ERROR” or “FATAL” message indicating that problem is printed to the console, and no information is updated in the SALTCONFIG
file. wsloadcf
exits with exit code 1.
A “WARN” message is printed to the console if: (1) configuration files may result in a potential run-time risk or (2) default values are used because they are not specified in the configuration files. “WARN” messages do not interrupt wsloadcf
execution.
Upon successful completion, wsloadcf
exits with exit code 0. If the SALTCONFIG
file is updated, a userlog message is generated.
SALT Web Service Definition File Reference
SALT Deployment File Reference