Administering the RPC Server for C with Local Scripts

The EntireX RPC Server for C allows standard RPC clients to communicate with servers written in C. It works together with the C Wrapper and calls standard libraries (Windows DLLs or UNIX shared objects/libraries).

This document describes how to administer the RPC Server for C with local scripts as in earlier versions of EntireX. It covers the following topics:

See also Administering the RPC Server for C with the Command Central GUI | Command Line.

Customizing the RPC Server

The following elements are used for setting up the RPC Server for C:

Configuration File

The name of the delivered example configuration file is cserver.cfg provided in the config folder. The configuration file contains the configuration for the RPC Server for C. The following settings are important:

  • connection information such as broker ID, server address (class, name, service)

  • scalability parameters

  • trace settings

  • etc.

For more information see Configuring the RPC Server.

Start Script

The start script for the RPC Server for C is called cserver.bsh (UNIX) or cserver.bat (Windows) and is provided in the bin folder of the installation directory. You may customize this file. The start script contains the following:

Configuring the RPC Server

The following rules apply:

  • In the configuration file:

    • Comments must be on a separate line.

    • Comment lines can begin with '*', '/' and ';'.

    • Empty lines are ignored.

    • Headings in square brackets [<topic>] are ignored.

    • Keywords are not case-sensitive.

  • Underscored letters in a parameter indicate the minimum number of letters that can be used for an abbreviated command.

    For example, in brokerid=localhost, brok is the minimum number of letters that can be used as an abbreviation, that is, the commands/parameters broker=localhost and brok=localhost are equivalents.

Parameter Default Values Req/
Opt
brokerid localhost Broker ID used by the server. See Using the Broker ID in Applications.

Example:
brokerid=myhost.com:1971

 R
class RPC Server class part of the server address used by the server. The server address must be defined as a service in the broker attribute file (see Service-specific Attributes). Case-sensitive, up to 32 characters. Corresponds to CLASS.

Example:
class=MyRPC

 R
codepage  

The codepage tells the broker the encoding of the data. The application must ensure the encoding of the data matches the codepage. The RPC server itself does not convert your application data. The application's data is shipped and received as given. Often, the codepage must also match the encoding used in the RPC server environment for file and terminal IO, otherwise unpredictable results may occur.

Under the Windows operating system:

  • By default, the Windows ANSI codepage configured for your system is automatically transferred to tell the broker how the data is encoded.

  • If you want to adapt the Windows ANSI codepage, see the Regional Settings in the Windows Control Panel and your Windows documentation.

  • If you want to encode the data different to your Windows ANSI codepage, convert the data in the application and provide the codepage name here. During receive, decode the data accordingly.

Under the UNIX operating system:

  • By default, no codepage is transferred to the broker.

  • It is assumed the broker's locale string defaults match. See Locale String Mapping. If they do not match, provide the codepage here. Example: 

codepage=iso-8859-1

Enable character conversion in the broker by setting the service-specific attribute CONVERSION to "SAGTRPC". See also Configuring ICU Conversion under z/OS | UNIX | Windows | BS2000 | z/VSE. More information can be found under Internationalization with EntireX.

R (UNIX)
O (Windows)
compresslevel N Enforce compression when data is transferred between broker and server. See Data Compression in EntireX Broker.

compresslevel= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8| 9 | Y | N

0-9 0=no compression
9=max. compression
N No compression.
Y Compression level 6.

Example:
compresslevel=6

 O
endworkers timeout
NEVER Defines worker model FIXED with a fixed number of worker threads. The number of worker threads is defined with minworkers. It does not increase or decrease during the lifetime of an RPC server instance.
TIMEOUT Defines slow-shrinking worker model DYNAMIC, where the number of worker threads is adjusted to the current number of client requests. With value TIMEOUT, all worker threads not used are stopped in the time specified by the timeout, except for the minimum number of active workers specified with minworkers. The upper limit of workers parallel active is restricted with maxworkers.
IMMEDIATE Defines fast-shrinking worker model DYNAMIC, where the number of worker threads is adjusted to the current number of client requests. With value IMMEDIATE, worker threads not used are stopped immediately as soon as they have finished their conversation, except for the minimum number of active workers defined with minworkers. The upper limit of workers active in parallel is restricted with maxworkers.

Example:
endworkers=timeout
minworkers=2
maxworkers=6
timeout=60

 O
library library =PREFIX(D) - PREFIX() library = search_logic [- library]
where search_logic is one of FIX(dllname) | PREFIX(prefix) | PREFIX(), and
  library can be repeated up to four times, that is, five entries are possible.
FIX(dllname) The IDL library name coming from the RPC client is ignored. You have to define the library names (Windows DLLs or UNIX shared objects/libraries).
PREFIX(prefix) The IDL library name coming from the RPC client is used to form the library name (Windows DLLs or UNIX shared objects/libraries). As prefix you can define any character. If an RPC client sends, for example, "SYSTEM" as the IDL library name and "D" is defined as prefix, the library name derived is "DSYSTEM".
PREFIX() The IDL library name coming from the RPC client is used as library name (Windows DLLs or UNIX shared objects/libraries).

Example FIX configuration:
library=FIX(MYSTUBS)-FIX(MYRPCS)

 O
logon YES Execute broker functions LOGON/LOGOFF in worker threads. Must match the setting of the broker attribute AUTOLOGON. Reliable RPC requires logon set to YES. See Reliable RPC.
NO No logon/logoff functions are executed.
YES Logon/logoff functions are executed.

Example:
logon=no

 O
minworkers 1 Minimum limit of worker threads.

  • For worker model DYNAMIC: minimum number of active worker threads, even if no RPC client requests have to be processed. This allows you to define a certain number of worker threads - not used by the currently executing RPC request - to wait for new RPC client requests to process. In this way the RPC server is ready to handle many RPC client requests arriving at the same time. Do not set a value higher than maxworkers.

  • For worker model FIXED: number of active worker threads. Do not set a value higher than 256.

See also endworkers.

Example:
minworkers=2

 O
maxworkers 10

Upper limit of all tasks concurrently. Do not set a value higher than 256. See also endworkers.

Example:
maxworkers=2

 O
password no default The password for secured access to the broker. If possible (write access) the password is encrypted and written to parameter password.e. The parameter password is removed. To change the password, add the parameter password with the new password as value.

Example:
password=MyPwd

 O
restartcycles 15 Number of restart attempts if the broker is not available. This can be used to keep the RPC Server for C running while the broker is down for a short time. A restart cycle will be repeated every 60 seconds.

Note:
Internally, the server waits in periods of 10 seconds (performing six times more cycles), which you can see in the server output.

When the number of specified cycles is reached and a connection to the broker is not possible, the RPC Server for C stops.

Example:
restartcycles=30

The server waits up to 30 minutes (30*6*10 seconds) before it terminates due to a missing broker connection.

 O
servername SRV1 Server name part of the server address used by the server. The server address must be defined as a service in the broker attribute file. See Service-specific Attributes. Case-sensitive, up to 32 characters. Corresponds to SERVER of the broker attribute file.

Example:
servername=mySrv

 R
service CALLNAT Service part of the server address used by the server. The server address must be defined as a service in the broker attribute file. See Service-specific Attributes. Case-sensitive, up to 32 characters. Corresponds to SERVICE attribute of the broker attribute file.

Example:
service=MYSERVICE

 R
ssl_file no default Set the SSL parameters. See Using SSL/TLS with the RPC Server for examples and more information. O
timeout 60 Timeout in seconds, used by the server to wait for broker requests. See broker ACI control block field WAIT for more information. Also influences restartcycles and worker model DYNAMIC.

Example:
timeout=300

 O
tracedestination ERXTrace.nnn.log

The name of the destination file for trace output. By default the main trace file name is ERXTrace.nnn.log, where nnn can be in the range from 001 to 005. See also Activating Tracing for the RPC Server.

  • Under UNIX, the trace file is located in the current working directory.

  • Under Windows, the trace file is located in a subfolder of the windows folder My Documents.

If the default is not used and a tracedestination is specified, you can use the following variables depending on the operating system:

%...% Windows Environment variable.
$(...) UNIX Environment variable.
@PID UNIX, Windows Process ID.
@TID UNIX, Windows Thread ID.
@RANGE[ n,m ] UNIX, Windows m must be greater than n, range is from 0 - 999
@CSIDL_PERSONAL Windows The user's home directory. The variable will be resolved by Windows shell functions.
@CSIDL_APPDATA Windows The Application Data Directory. The variable will be resolved by Windows shell functions.
@CSIDL_LOCAL_APPDATA Windows The Local Application Data Directory. The variable will be resolved by Windows shell functions.

See also Activating Tracing for the RPC Server.

Example:
tracedestination=ERXTrace.log

 O
tracelevel None Trace level for the server. See also Activating Tracing for the RPC Server. 
tracelevel = None | Standard | Advanced | Support
None No trace output.
Standard For minimal trace output.
Advanced For detailed trace output.
Support This trace level is for support diagnostics and should only be switched on when requested by Software AG support.

Example:
tracelevel=standard

 O
traceoption None Additional trace option if trace is active. See also Activating Tracing for the RPC Server.
None No additional trace options.
STUBLOG If tracelevel is Advanced or Support, the trace additionally activates the broker stub log.
NOTRUNC Normally if a data buffer larger than 8 KB is traced, the buffer trace is truncated. Set this option to write the full amount of data without truncation.

Note:
This can increase the amount of trace output data dramatically if you transfer large data buffers.

Example:
traceoption=(STUBLOG,NOTRUNC)

 O
userid ERX-SRV The user ID for access to the broker. The default ERX-SRV will be used if this parameter is omitted or specified without a value: "userid=".

Example:
userid=MyUid

 O

Locating and Calling the Target Server

The IDL library and IDL program names that come from the RPC client are used to locate the server interface objects and your customer-written C servers. See library-definition and program-definition. This two-level concept (library and program) has to be mapped to the RPC Server for C environment. The called C servers and server interface objects are implemented as libraries (shared objects/libraries under UNIX; DLLs under Windows). Those libraries also have a two-level concept: file name and entry point name.

graphics/intro_sio.png

See also Server Interface Objects and C Server in the Introduction.

As an example, assume the RPC client sends the IDL library name "EXAMPLE" and IDL program "CALC":

  • Server interface object
    For the file name(2), the character "D" is used as a prefix to the IDL library name sent from the RPC client. The resulting name is "DEXAMPLE". For the entry point name(3), the character "D" is used as a prefix to the IDL program name send from the RPC client. The resulting name is "DCALC".

    • Under UNIX: A shared library/object with file name(1) DEXAMPLE.so|sl and entry point DCALC must be accessible through the standard UNIX shared library load mechanism.

    • Under Windows: A DLL named DEXAMPLE.DLL and entry point DCALC must be accessible through the standard Windows DLL load mechanism.

  • C Server file (written by customer)
    For the file name(2), the IDL library name sent from the RPC client is used directly. The resulting name is "EXAMPLE". For the entry point (written by customer) name(4), the IDL program name sent from the RPC client is used directly. The resulting name is "CALC".

    • Under UNIX: A shared library/object with file name(1) EXAMPLE.so|sl and entry point CALC must be accessible through the standard UNIX shared library load mechanism.

    • Under Windows: A DLL named EXAMPLE.DLL and entry point CALC must be accessible through the standard Windows DLL load mechanism.

Notes:

  1. Under UNIX, file names are case sensitive. The IDL library name must exactly match the name of the shared library/object.
  2. The mechanism to form the file names can be modified with the library parameter. The description here assumes default settings with PREFIX(D) - PREFIX(). These match the standard names produced by the C Wrapper.
  3. The prefix for the entry point name of the server interface object is always "D". It does not depend on the library parameter.
  4. The entry point name for the called C server must match the IDL program name.

Using SSL/TLS with the RPC Server

RPC servers can use Secure Sockets Layer/Transport Layer Security (SSL/TLS) as the transport medium. The term "SSL" in this section refers to both SSL and TLS. RPC-based servers are always SSL clients. The SSL server can be either the EntireX Broker, Broker SSL Agent, or Direct RPC in webMethods Integration Server (IS inbound). For an introduction see SSL/TLS and Certificates with EntireX in the Platform-independent Administration documentation.

Start of instruction setTo use SSL

  1. To operate with SSL, certificates need to be provided and maintained. Depending on the platform, Software AG provides default certificates, but we strongly recommend that you create your own. See SSL/TLS Sample Certificates Delivered with EntireX in the EntireX Security documentation.

  2. Specify the Broker ID, using one of the following styles:

    If no port number is specified, port 1958 is used as default.

  3. Specify SSL parameters, using one of the methods below:

    • As part of the Broker ID
      The simplest way to specify short SSL parameter is to add them to the Broker ID.

      Example with URL-style Broker ID:

      ssl://localhost:2010?VERIFY_SERVER=N&TRUST_STORE=c:\\certs\\CaCert.pem

      Example with transport-method-style Broker ID:

      ETB024:1609:SSL?VERIFY_SERVER=N&TRUST_STORE=c:\\certs\\CaCert.pem

    • In the SSL file
      Complex SSL parameters can be specified in a so-called SSL file, a text file containing the parameters.

      1. Define the SSL file with the SSL parameters, for example file mySSLParms.txt with the following contents: 

        VERIFY_SERVER=N
TRUST_STORE=c:\\certs\\CaCert.pem

      2. Define the SSL file in the configuration file of the RPC Server for C. See parameter ssl_file under Configuring the RPC Server. Example: 

        brokerid=ssl://localhost:2010
.
.
ssl_file=C:\mySSLdirectory\mySSLParms.txt

    If the SSL client checks the validity of the SSL server only, this is known as one-way SSL. The mandatory trust_store parameter specifies the file name of a keystore that must contain the list of trusted certificate authorities for the certificate of the SSL server. By default a check is made that the certificate of the SSL server is issued for the hostname specified in the Broker ID. The common name of the subject entry in the server's certificate is checked against the hostname. If they do not match, the connection will be refused. You can disable this check with SSL parameter verify_server=no.

    If the SSL server additionally checks the identity of the SSL client, this is known as two-way SSL. In this case the SSL server requests a client certificate (the parameter verify_client=yes is defined in the configuration of the SSL server). Two additional SSL parameters must be specified on the SSL client side: key_store and key_passwd. This keystore must contain the private key of the SSL client. The password that protects the private key is specified with key_passwd.

    The ampersand (&) character cannot appear in the password.

    SSL parameters are separated by ampersand (&). See also SSL/TLS Parameters for SSL Clients.

  4. Make sure the SSL server to which the RPC Server for C connects is prepared for SSL connections as well. The SSL server can be EntireX Broker, Broker SSL Agent, or Direct RPC in webMethods Integration Server (IS inbound). See:

Starting the RPC Server

Before starting, make sure all your server interface objects and (customer-written) C servers are accessible through the standard Windows DLL or UNIX shared library/object load mechanism. See also Locating and Calling the Target Server.

Start of instruction setTo start the RPC Server for C

  • Use the Start Script.

    Or:
    Use the following format: 

    rpcserver CFG=name [-option] [brokerid] [class] [servername] [service]

    Here are some sample options. See Configuring the RPC Server for full list.

    -serverlog file Defines an alternative log file. Under Windows, this is typically used by Windows Services. See Running an EntireX RPC Server as a Windows Service.
    -s[ilent] Run the RPC server in silent mode, that is, no terminal input will be required (for example to acknowledge error messages). The batch scripts will terminate automatically. Under UNIX, this is recommended when running in background mode.
    -TraceDestination file Set the trace destination parameter.
    -TraceLevel None|Standard|Advanced Set the trace level parameter.

    Note:
    The server input arguments are resolved from left to right. Parameters defined in the configuration file may be overridden by parameters applied on the command line and vice versa. See Configuring the RPC Server for full list of options.

    Or:
    Under Windows you can use the RPC Server for C as a Windows Service. See Running an EntireX RPC Server as a Windows Service.

Stopping the RPC Server

Start of instruction setTo stop the RPC Server for C

Running an EntireX RPC Server as a Windows Service

For general information see Running an EntireX RPC Server as a Windows Service.

Start of instruction setTo run the RPC Server for C as a Windows Service

  1. Customize the Start Script according to your system installation.

    Note:
    The script file must pass external parameters to the RPC server and use the option –silent: 

    rpcserver CFG=..\config\cserver.cfg  -s %*

    See also Starting the RPC Server.

  2. Test your RPC server to see whether it will start if you run your script file.

  3. Use the EntireX RPC Service Tool and install the RPCService with some meaningful extension, for example MyServer. If your Start Script is cserver.bat, the command will be 

    RPCService -install -ext MyServer -script install_path\EntireX\bin\cserver.bat

    The log file will be called RPCservice_MyServer.log.

  4. In Windows Services menu (Control Panel > Administrative Tools > Services) select the service: Software AG EntireX RPC Service [MyServer] and change the property Startup Type from "Manual" to "Automatic".

Activating Tracing for the RPC Server

Start of instruction setTo switch on tracing for the RPC Server for C

  1. Set the parameters tracelevel, traceoption and tracedestination. See Configuring the RPC Server.

  2. Start the RPC Server for C. See Starting the RPC Server.

  3. To evaluate the return codes, see Component Return Codes in EntireX.

Start of instruction setTo switch off tracing