Skip to main content
Skip table of contents

Migrating SOAPam Server services to LightWave Server

Create SOAPam Server Users and Groups in LightWave Server

Users and Groups in LightWave Server are conceptually similar to User and Groups in SOAPam Server. To migrate the Users and Groups, manually recreated any necessary SOAPam Server Users and Groups in LightWave Server. If your existing SOAPam Server services use Anonymous access, it may not be necessary to migrate any Users or Groups.

Create LightWave Server Access Control Policies

LightWave Server service access control is fundamentally different than SOAPam Server. The differences are summarized in this table:

SOAPam Server

LightWave Server

Access to services is controlled by setting access permissions on the File System folder containing the service SDF, using the File System Browser. The same access is granted for all services (SDFs) in the File System folder.

Access to services is controlled by creating Access Control Policies (ACPs) that can then be applied to deployed Services. Access Control Policies can be applied to one or more services.

User and Group access to a service is controlled by the User or Groups access to the File System folder containing the SDF.

User and Group access is specified in the Access Control Policy.

Service IP address restrictions are set at the Server level using Access Control Management.

IP address restrictions are set in the Access Control Policy.

Import the SOAPam Server Service Definition File into LightWave Server

The LWSCOM utility is used to import SDF files into LightWave Server, creating an API Definition and associated Dictionary. Throughout these examples, the SOAPam Server echoStringSample service. This service is contained in the SDF file echoString.sdf and is automatically installed in the SOAPam Server in folder /services/samples/echoString.

To import the SDF into LightWave Server using LWSCOM, the SDF must be located in the Enscribe filesystem. Copy the SDF from the SOAPam Server VFS to the Enscribe file system using VFSMGR or any other means appropriate for your environment.

CODE
run vfsmgr -get file /services/samples/echoString/echoString.sdf echosdf !

Once the SDF file is available in the Enscribe filesystem, it can be imported into LightWave Server. The syntax of the LWSCOM IMPORT SDF command is:

CODE
LWSCOM 1-> help import sdf

IMPORT SDF Command

Imports an SDF from a file into the filesystem as a LightWave DICTIONARY and
an API.

  IMPORT SDF <file-name>
         , API-NAME { <api-name> | * } [ ! ]
         , DICTIONARY-NAME { <dictionary-name> | * } [ ! ]

<file-name>

  Filename of the SDF to import.

API-NAME { <api-name> | * } [ ! ]

  The name to be used for the imported API, or '*' to use an API name derived
  from the SDF.

DICTIONARY-NAME { <dictionary-name> | * } [ ! ]

  The name to be used for the imported DICTIONARY, or '*' to use a DICTIONARY
  name derived from the SDF.

For example, to import the Echo String Sample SDF, use this command:

CODE
run lwscom import sdf ECHOSDF, api-name * !, dictionary-name * !

Deploy the Imported API as a LightWave Server Service

To complete the migration, deploy the imported API as a LightWave Server service. This can be done from the LightWave Server Console, or using the LWSCOM Utility. To deploy using the Console, follow these steps:

  • Sign in to the Console.

  • From the side menu, select Services.

  • In the upper right corner, select the '+' icon.

  • To deploy the Echo String Service, enter the following:

    • Name: “echoStringSample”

    • Description: “This service implements the echoString sample”

    • Version: use default “1.0”

    • API: “echoStringSample”

    • Access Control Policy: allow-anonymous-access or any other appropriate ACP

    • TCP/IP Port Range: leave blank

    • Service Base Path: /services/samples/echoString/echoString

    • Enabled: checked

Note: it is important that the correct Service Base Path be configured in order for the correct SOAP service endpoint to be deployed. The Service Base Path for SOAPam compatible services is simply the full path of the SOAPam SDF file, without the “.sdf” extension. For example:

SOAPam SDF location

Service Base Path

/services/samples/echoString/echoString.sdf

/services/samples/echoString/echoString

/services/transactionControl/transactionControl.sdf

/services/transactionControl/transactionControl

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.