Table of Contents

Search

  1. Preface
  2. Introduction
  3. Servers
  4. Console Client
  5. Search Clients
  6. Table Loader
  7. Update Synchronizer
  8. Globalization
  9. Siebel Connector
  10. Web Services
  11. ASM Workbench
  12. Cluster Merge Rules
  13. Forced Link and Unlink
  14. System Backup and Restore
  15. Batch Utilities

XML Search Service

XML Search Service

Deploying the XML Search Service

MDM Registry Edition provides a web-based XML Search Service. The service is implemented by the XML Search Server, as part of the
ssasrsv
executable image.

Enabling

The XML Search Server does not start unless it has been enabled and configured. The XML Search Server is enabled by allocating the server’s host name (
SSA_XMHOST
) and port number (
SSA_XMPORT
) in the
env\mdmres.bat
(Windows) or
env/mdmres
(UNIX). The default port number of the XML Search Service Server is 1670.

Configuring

The configuration process consists of creating a simple text file named either
xmserv.ini
or
xmserv.xml
. The two different extensions represent two different formats that the configuration file can take; an INI file form and an XML form.
The file can be located in
$SSAINI
,
$HOME
or
$SSABIN
, which the server searches in that order.
The content of this file determines which searches and Rulebases are visible to the client. It is read at server initialization, so changes to the configuration become effective only after the XML Search Server is restarted or refreshed.
The
xmserv.ini
form has the same format as the htserv.ini file used by the HTTP Search Server. Refer to the
HTTP Search Client
section of the
OPERATIONS Guide
for instructions on how to use this format.
Since this is a Web Service, the XML format is recommended.

Generic Mode

The simplest possible file contains the following tags:
<?xml version="1.0" encoding="UTF-8"?> <server xmlns="http://www.identitysystems.com/xmlschema/iss-version-1/xmlserv"> <mode>generic</mode> <rulebase>ids:rb</rulebase> </server>
Use the simple
xmserv.xml
file to make all searches in the
Rulebase ids:rb
available.
Unlike the HTTP Search Server, you must specify a Rulebase for the XML Search server.
Rulebase names are sent from the client to the server in the clear using the HTTP protocol. To avoid passing database passwords, it is strongly recommended that
xmserv.xml
files should use
Dictionary Alias
names. If you did not, the same file would look something like:
<?xml version="1.0" encoding="UTF-8"?> <server xmlns="http://www.identitysystems.com/xmlschema/iss-version-1/xmlserv"> <mode>generic</mode> <rulebase>odb:0:userid/topsecretpassword@dbserver6</rulebase> </server>

Custom Mode

Use the custom mode to configure the systems, searches and Rulebases for the Web clients. You can define one or more profiles. Each profile contains rules that define the Rulebase name, system name, and one or more search definitions.
You can use the
sdf_view
parameter to specify the output view that you define in the SDF file for each search definition. A SOAP response might contain different fields for the matching records based on the output views that you specify in the
xmserv.xml
file.
The following sample
xmserv.xml
file defines a single profile in the custom mode:
<?xml version="1.0" encoding="UTF-8"?> <server xmlns="http://www.identitysystems.com/xmlschema/iss-version-1/xmlserv"> <mode>custom</mode> <profile name="search profile"> <rule name="search rule"> <rulebase>ids:rb</rulebase> <system>ssa001</system> <search name="search name"> <sdf_search>name-search</sdf_search> <sdf_view>View2</sdf_view> </search> </rule> </profile> </server>
The following sample
xmserv.xml
file defines multiple profiles in the custom mode:
<?xml version="1.0" encoding="UTF-8"?> <server xmlns="http://www.identitysystems.com/xmlschema/iss-version-8/xmserv"> <mode>custom</mode> <profile name="Profile 1"> <rule name="rule2"> <rulebase>ids:rb2</rulebase> <system>ssa001</system> <search name="Name Search"> <sdf_search>name-search</sdf_search> <sdf_view>View2</sdf_view> </search> </rule> </profile> <profile name="Profile 2"> <rule name="rule3"> <rulebase>ids:rb3</rulebase> <system>ssa001</system> <search name="Name Search"> <sdf_search>name-search</sdf_search> <sdf_view>View3</sdf_view> </search> </rule> <rule name="rule1"> <rulebase>ids:rb</rulebase> <system>ssa001</system> <search name=" Name Search"> <sdf_search>name-search</sdf_search> <sdf_view>View1</sdf_view> </search> </rule> </profile> </server>
In the preceding example, you have three rules for three systems, named ssa001, and probably identical, but perhaps residing in three different Rulebases. In this case, four WSDL files will be generated, called
rule1.wsdl
,
rule2.wsdl
,
rule3.wsdl
and
ssa001.wsdl
. The
ssa001.wsdl
file will correspond to
rule1
. Each will have its own target namespace. That of
ssa001.wsdl
will be
http://www.identitysystems.com/xmlschema/iss-version-8/searchSvc
while
rule1.wsdl
,
rule2.wsdl
, and
rule3.wsdl
will use the following namespaces:
http://www.identitysystems.com/xmlschema/iss-version-8/searchSvc/rule1 http://www.identitysystems.com/xmlschema/iss-version-8/searchSvc/rule2 http://www.identitysystems.com/xmlschema/iss-version-8/searchSvc/rule3
Two rules cannot have the same name. The server will issue an error.

WSDL File

WSDL files are created in the server work directory for each rule and system defined in the
xmserv.xml
file when the server starts or is refreshed.
The WSDL can also be accessed through the server at:
http://<xmhost>:<xmport>/?<system>.wsdl
Which will correspond to the last-named system of that name in the
xmserv.xml
file. For example, the sample system will usually be found at:
http://localhost:1670/?ssa001.wsdl
The WSDL can also be retrieved from:
http://<xmhost>:<xmport>/?<rule>.wsdl

Re-generating the WSDL File

The WSDL file can be regenerated by issuing a flush command to the server. The server will re-read the
xmserv.xml
file and re-create the WSDL file. On a Unix platform this would be done by:
$SSABIN/ssashut -h$SSA_XMHOST -f
Or on Windows:
%SSABIN%\ssashut -h%SSA_XMHOST% -f
If a system or search is deleted, it should be manually removed from the
xmserv.xml
file and a flush command should be issued to the server to remove the corresponding web service.
Searches are cached. If a system is modified, a flush command should be issued to the server to regenerate the WSDL file and flush the search cache.

Creating a .NET Proxy

A proxy can be created from the WSDL generated by the XML Search Server using
wsdl.exe
, which is part of the Microsoft .NET SDK. Given the WSDL created from the sample system SSA001 (which can also be found in the
MDM-RE samples\programs\csharp-xml
directory), one can create a proxy with:
wsdl /out:ssa001.cs ssa001.wsdl
This creates a C#
public class
called IDT001.
public class IDT001 { public int score; public string ID; public string Name; public string DOB; public string Address; }
This can be then be compiled with:
csc /target:library /out:ssa001.dll ssa001.cs
and linked with a client like
ws-sample1.cs
in the
MDM-RE samples\programs\csharp-xml
directory.
csc /target:exe /reference:ssa001.dll ws-sample1.cs
The samples can be built with the supplied
compile.bat
script. If you have Microsoft Web Service Extensions (WSE) 3.0 installed, you may prefer to compile with that instead. The script accepts an argument that instructs it to use WSE 3.0:
compile wse3
At the heart of the
ws-sample1.cs
sample is:
try { ssa001 search = new ssa001 (); IDT001[] results = search.namesearch ( name,address, dob, null, null, null, workdir, search_width, match_tolerance); foreach (IDT001 idt in results) { Console.WriteLine ("{0} {1,-24} {2}", idt.score, idt.Name, idt.Address); } } catch (SoapException se) { Console.Error.WriteLine (se.Message); } catch (WebException we) { Console.Error.WriteLine (we.Message); }
From this, we can see that:
  • The search class has the name of the MDM-RE system.
  • The response class has that of the IDT defined in the MDM-RE system.
  • The search class contains search methods, which bear the names of the searches defined in the system.
  • The searches take parameters which are the fields of the search, plus four options (see below).
  • In every case, you can get the default by passing a
    null
    parameter to the method.
  • Errors are thrown as
    SOAPException
    exceptions.
  • There is also the possibility of a
    WebException
    exception, which may occur if you try to run the client without bringing the server up.
Optional parameters:
LOGOUT
Filename for server output for this session.
LOGERR
Filename for server errors for this session.
LOGTEST
Filename for server search trace for this session.
WORKDIR
Used to inform the Search Server which directory is to be used as the working directory for this session.
Search_width
Specifies either
Narrow
,
Typical
or
Exhaustive
to nominate how many candidates should be selected.
Match_tolerance
Specifies either
Conservative
,
Typical
or
Loose
to nominate how aggressive the matching scheme should be in rejecting candidates

Apache Axis2

An Apache Axis2 sample called
Axis2Sample.java
is included with the Java samples. If you have Apache Axis2 installed, and you paths and classpaths set up correctly, you can build a proxy with:
wsdl2java -uri ssa001.wsdl -d adb -s -p ssa001
Then compile it with:
javac ssa001/Ssa001Stub.java ssa001/Ssa001Fault.java
And compile the sample with:
javac Axis2Sample.java

Running the Samples

To get the samples to run you need to load the sample system and create an
xmserv.xml
file similar to the simple example above.

SOAP Request

The
ws-sample1.cs
sample program will generate a SOAP 1.1 request that will look something like this:
<?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soap:Body> <name-search xmlns="http://www.identitysystems.com/xmlschema/iss-version-8/searchSvc" WORKDIR="d:\a2mi\ids\testx270.dir" search_width="Typical" match_tolerance="Loose" system_name="ssa001"> <Name>J Smythe</Name> <Address>157 cathy st</Address> <DOB>19491231</DOB> </name-search> </soap:Body> </soap:Envelope>

SOAP Response

The response takes the form of a SOAP envelope with an element in the body with the name of the search followed by "
_response
." This contains a result element named after the IDT, with "
Result
" added which in turn contains the IDT fields, plus an additional one called "
score
". All names are exactly as they appear in the System Definition File.
<?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-utility-1.0.xsd"> <soap:Body> <name-search_response xmlns="http://www.identitysystems.com/xmlschema/iss-version-8/searchSvc"> <Search01Result> <Search01> <score>85</score> <ID>1617</ID> <Name>M J SMITH</Name> <DOB>19491018</DOB> <Address>4/157 CARTHAGE STREET</Address> <CL_ID /> </Search01> <Search01> <score>80</score> <ID>0000001617</ID> <IDS-IDX-IO>00000023</IDS-IDX-IO> <IDS-IDT-IO>00000000</IDS-IDT-IO> <IDS-KSL-ACCEPTED-COUNT>00000000</IDS-KSL-ACCEPTED-COUNT> <IDS-KSL-UNDECIDED-COUNT>00000001</IDS-KSL-UNDECIDED-COUNT> <IDS-KSL-REJECTED-COUNT>00000019</IDS-KSL-REJECTED-COUNT> <IDS-KSL-TOTAL-COUNT>00000020</IDS-KSL-TOTAL-COUNT> </Search01> (more...) </Search01Result> </name-search_response> </soap:Body> </soap:Envelope>
The SOAP response might contain different fields for the search results based on the output view that you specify in the
xmserv.xml
file.

Match Explain API

In addition to the XML Search Web Service, there is also an XML Match Explain Web Service. An XML Match Explain request takes two records, known as the search and file records, and describes the reasons why a match scored what it did. The search and file records have the same format as the search record used by the XML SearchWeb Service.
An XML Match Explain request looks like this:
<?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <env:Header xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <wsa:Action /> <wsa:MessageID>urn:uuid:534141cc-e1c1-48d0-97f8-a5a3e38244f7</wsa:MessageID> <wsa:ReplyTo> <wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address> </wsa:ReplyTo> <wsa:To>http://host:1665/</wsa:To> <wsse:Security> 126 Chapter 9: Web Services <wsu:Timestamp wsu:Id="Timestamp-57d31233-8456-4920-9dac-cb01cb261861"> <wsu:Created>2010-03-30T03:58:40Z</wsu:Created> <wsu:Expires>2010-03-30T04:03:40Z</wsu:Expires> </wsu:Timestamp> </wsse:Security> </env:Header> <soap:Body> <Explain-name-search xmlns="http://www.identitysystems.com/xmlschema/iss-version-8/searchSvc" match_tolerance="Loose" system_name="ssa001"> <Explain-name-search-search> <Name>J Smythe</Name> <DOB>19491231</DOB> <Address>157 cathy st</Address> </Explain-name-search-search> <Explain-name-search-file> <Name>John Smithe</Name> <DOB>19491231</DOB> <Address>157 cathy st</Address> </Explain-name-search-file> </Explain-name-search> </soap:Body> </soap:Envelope>
The response will look like this:
<?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://www.w3.org/2005/03/addressing" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-utility-1.0.xsd"> <soap:Header> <wsa:MessageID>urn:uuid:631cb7e4-2e05-4e3f-b6a2-e0968da50e91</wsa:MessageID> <wsa:Action>name-search</wsa:Action> <wsa:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To> <wsa:From> <wsa:Address>http://host:1665</wsa:Address> </wsa:From> <wsse:Security> <wsu:Timestamp wsu:Id="Timestamp-aacd0899-39ce-473f-b570-0e7d5c373e06"> <wsu:Created>2010-03-30T04:58:40Z</wsu:Created> <wsu:Expires>2010-03-30T05:03:40Z</wsu:Expires> </wsu:Timestamp> </wsse:Security> </soap:Header> <soap:Body> <Explain-name-search_response xmlns="http://www.identitysystems.com/xmlschema/iss-version-8/searchSvc"> <Explain-Result Record-Type="0"> <Explain-Summary Parent-Sequence-Number="0" Sequence-Number="1"> <Score>92</Score> <Decision>A</Decision> </Explain-Summary> </Explain-Result> <Explain-Result Record-Type="1"> <Explain-Operator Parent-Sequence-Number="1" Sequence-Number="2"> <Type>03</Type> </Explain-Operator> </Explain-Result> <Explain-Result Record-Type="2"> <Explain-Purpose Parent-Sequence-Number="2" Sequence-Number="3"> <Name>Person_Test</Name> <Score>92</Score> <Decision>A</Decision> <Match-Level>Typical</Match-Level> <Accept-Limit>89</Accept-Limit> <Reject-Limit>70</Reject-Limit> <Early-Exit-Taken>false</Early-Exit-Taken> </Explain-Purpose> </Explain-Result> <Explain-Result Record-Type="4"> <Explain-Method Parent-Sequence-Number="3" Sequence-Number="4"> <Field-Name>Person_Name</Field-Name> <Score>86</Score> <Weight>400</Weight> <Original-Weight>4</Original-Weight> <Weight-Flag>W</Weight-Flag> <Contributed>true</Contributed> <Optional>false</Optional> <Contribution>49</Contribution> <Repeating-Field>false</Repeating-Field> <Search-Index-Used>0</Search-Index-Used> <File-Index-Used>0</File-Index-Used> </Explain-Method> </Explain-Result> <Explain-Result Record-Type="5"> <Explain-Data Parent-Sequence-Number="4" Sequence-Number="5"> <Type>S</Type> <data>John Smithe</data> </Explain-Data> </Explain-Result> <Explain-Result Record-Type="5"> <Explain-Data Parent-Sequence-Number="4" Sequence-Number="6"> <Type>F</Type> <data>J Smythe</data> </Explain-Data> </Explain-Result> <Explain-Result Record-Type="4"> <Explain-Method Parent-Sequence-Number="3" Sequence-Number="7"> <Field-Name>Address_Line1</Field-Name> <Score>100</Score> <Weight>200</Weight> <Original-Weight>2</Original-Weight> <Weight-Flag>W</Weight-Flag> <Contributed>true</Contributed> <Optional>true</Optional> <Contribution>28</Contribution> <Repeating-Field>false</Repeating-Field> <Search-Index-Used>0</Search-Index-Used> <File-Index-Used>0</File-Index-Used> </Explain-Method> </Explain-Result> <Explain-Result Record-Type="5"> <Explain-Data Parent-Sequence-Number="7" Sequence-Number="8"> <Type>S</Type> <data>157 cathy st</data> </Explain-Data> </Explain-Result> <Explain-Result Record-Type="5"> <Explain-Data Parent-Sequence-Number="7" Sequence-Number="9"> <Type>F</Type> <data>157 cathy st</data> </Explain-Data> </Explain-Result> <Explain-Result Record-Type="4"> <Explain-Method Parent-Sequence-Number="3" Sequence-Number="10"> <Field-Name>Date</Field-Name> <Score>100</Score> <Weight>100</Weight> <Original-Weight>1</Original-Weight> <Weight-Flag>W</Weight-Flag> <Contributed>true</Contributed> <Optional>true</Optional> <Contribution>14</Contribution> <Repeating-Field>false</Repeating-Field> <Search-Index-Used>0</Search-Index-Used> <File-Index-Used>0</File-Index-Used> </Explain-Method> </Explain-Result> <Explain-Result Record-Type="5"> <Explain-Data Parent-Sequence-Number="10" Sequence-Number="11"> <Type>S</Type> <data>19491231</data> </Explain-Data> </Explain-Result> <Explain-Result Record-Type="5"> <Explain-Data Parent-Sequence-Number="10" Sequence-Number="12"> <Type>F</Type> <data>19491231</data> </Explain-Data> </Explain-Result> <Explain-Result Record-Type="1"> <Explain-Operator Parent-Sequence-Number="1" Sequence-Number="13"> <Type>04</Type> </Explain-Operator> </Explain-Result> </Explain-name-search_response> </soap:Body> </soap:Envelope>
Refer to the
Match Explain API
section of the
DEVELOPER GUIDE
for a description of the meanings of these fields.

Web Services Addressing

MDM-RE Web Services supportsWeb Services Addressing.

Web Services Addressing Standards

MDM-RE Web Services supports the Web Services Addressing 1.0 - Core W3C Recommendation dated 9 May 2006, Web Services Addressing 1.0 - SOAP Binding W3C Recommendation dated 9 May 2006, and Web Services Addressing 1.0 - WSDL Binding W3C Candidate Recommendation dated 29 May 2006.
To deploy this facility on, start the servers by running the shell script
$SSABIN/idsup
on Unix or the batch script
%SSABIN%\idsup.bat
on Windows with the following option:
-qca1.0
Specifies that
WS-Addressing 1.0
will be used
With
WS-Addressing
, a request will be as follows:
<?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <env:Header xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <wsa:Action /> <wsa:MessageID>urn:uuid:ec859556-55c3-4256-83bc-e134902f1323</wsa:MessageID> <wsa:ReplyTo> <wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address> </wsa:ReplyTo> <wsa:To>http://host:1670/</wsa:To> <wsse:Security> <wsu:Timestamp wsu:Id="Timestamp-0d7269e6-691f-4539-bab8-a44677b78d00"> <wsu:Created>2009-07-10T00:16:50Z</wsu:Created> <wsu:Expires>2009-07-10T00:21:50Z</wsu:Expires> </wsu:Timestamp> </wsse:Security> </env:Header> <soap:Body> <name-search xmlns="http://www.identitysystems.com/xmlschema/iss-version-8/searchSvc" WORKDIR="d:\a2mi\ids\testx270.dir" search_width="Typical" match_tolerance="Loose" system_name="ssa001"> <Name>J Smythe</Name> <Address>157 cathy st</Address> <DOB>19491231</DOB> </name-search> </soap:Body> </soap:Envelope>
With
WS-Addressing
switched on, the servers will require a valid
WS-Addressing
header to be present.
The servers will validate the security timestamp, if present. You may therefore need to ensure that your server machine’s clock is accurate.
The response will be as follows:
<?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsa="http://www.w3.org/2005/03/addressing" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-utility-1.0.xsd"> <soap:Header> <wsa:MessageID>urn:uuid:38bfb6b5-ce10-4768-aaa9-852d1e55605f</wsa:MessageID> <wsa:Action>name-search</wsa:Action> <wsa:To>http://www.w3.org/2005/03/addressing/role/anonymous</wsa:To> <wsa:From> <wsa:Address>http://host:1670</wsa:Address> </wsa:From> <wsse:Security> <wsu:Timestamp wsu:Id="Timestamp-86d8102a-ed7f-4bea-bee1-dd17b8dc954a"> <wsu:Created>2009-07-10T01:00:31Z</wsu:Created> <wsu:Expires>2009-07-10T01:05:31Z</wsu:Expires> </wsu:Timestamp> </wsse:Security> </soap:Header> <soap:Body> <name-search_response xmlns="http://www.identitysystems.com/xmlschema/iss-version-8/searchSvc"> <Search01Result> <Search01> <score>85</score> <ID>1617</ID> <Name>M J SMITH</Name> <DOB>19491018</DOB> <Address>4/157 CARTHAGE STREET</Address> <CL_ID /> </Search01> <Search01> <score>70</score> <ID>1647</ID> <Name>JACK SMITH</Name> <DOB>19201220</DOB> <Address>22 BRUCE STREET</Address> <CL_ID /> </Search01> (more...) </Search01Result> </name-search_response> </soap:Body> </soap:Envelope>

Web Services Security

MDM-RE Web Services supports Web Services Security.

Web Services Security Standards

MDM-RE Web Services supports the Web Services Security SOAP Message Security 1.1 (WS-Security 2004) OASIS Standard Specification dated 1 February 2006.

Samples

The sample
ws-sample3.cs
, which requires WSE 3.0, uses a supplied sample X509 RSA certificate to create a message which is signed with private key. A copy of the X509 RSA certificate is included in the message.
The MDM-RE servers use the supplied public RSA key to validate the request.

Transport Layer Security

MDM-RE web services can employ HTTPS to implement Transport Layer Security. This will provide point to point security. To deploy this facility on, start the servers by running the shell script
$SSABIN/idsup
on Unix or the batch script
%SSABIN%\idsup.bat
on Windows with the following options:
-qcFile1
Specifies the PEM file containing an X509 certificate.
-qkFile2
Specifies the PEM file containing an RSA private key.
-qrFile3
Specifies the PEM file containing an X509 root certificate.
The web service will now use HTTPS instead of
HTTP. HTTPS
sends HTTP messages using SSL, a well established and widely available security protocol. If HTTPS is specified, any messages sent to the web service using HTTP will be discarded.
All three options must be specified. The server will report an error on startup if one is omitted.

Timeout Period for XML Search Server

You can specify the timeout periods as a comma-separated list for the XML Search Server when you start the
MDM Registry Edition
Server.
To specify the timeout periods when you start the
MDM Registry Edition
Server, perform the following task:
  • On Windows: On a command line, run the
    idsup.bat -qt"<Idle>,<Connection>,<Read>,<Write>"
    command from the
    <MDM Registry Edition Installation Directory>\bin
    directory.
  • On UNIX: On a shell command line, run the
    idsup -qt<Idle>,<Connection>,<Read>,<Write>
    command from the
    <MDM Registry Edition Installation Directory>/bin
    directory.
The
idsup
command uses the following parameters:
Idle
A client session to remain idle before the server cancels the session. Specify the timeout period in seconds. Set the value as 0 if you want to use the default time period.
Connection
A connection to the server to wait before terminating the attempt. Specify the timeout period in seconds. Set the value as 0 if you want to use the default time period.
Read
A read or receive operation to complete successfully. Specify the timeout period in seconds. Set the value as 0 if you want to use the default time period.
Write
A write or send operation to complete successfully. Specify the timeout period in seconds. Set the value as 0 if you want to use the default time period.

0 COMMENTS

We’d like to hear from you!