Deploying a Service Description

This topic contains information about how to deploy an HCL Domino Leap Service Description.

To add a new Service Description, you must have at least Editor access to VoltConfig.nsf. Perform the following steps:
  1. Using the Notes client, open VoltConfig.nsf.
  2. Select the All Service Descriptions view.
  3. Select the New Description action in the ribbon at the top of the view.
  4. Give your service a name. Usually, the Name field has the same value as the name element in your Service Description XML.

    Optionally give your service a description. The Description field is not required, but it may help you remember the purpose of the service.

  5. Paste your service description into the XML field.
  6. Select Done. Then select Yes to save the new document.

When the Domino Leap server starts, it scans the All Service Descriptions view for new, deleted, and changed Service Descriptions. New and changed Service Descriptions are loaded and registered with the Domino Leap server, and become available immediately. Service Descriptions that fail to load, or do not have an appropriate Service Transport registered, are not available.

Access to a service description may be given to a specific user, group, or special assignment (i.e. Authenticated, Anonymous, etc). The access control is made up of two parts: who may discover and work with the service while designing an application, and who may run the service. Users or Groups provided must be in the proper format - it is recommended to use the dialog (by clicking the button with the down arrow) when adding permissions. Adding or removing users does not require a server restart, but there will be a short delay before the changes take effect.

Deleting Service Descriptions and changing Service Descriptions must be done carefully. Applications might depend on any or all of the parameters for the Service Description, as well as data returned within the Service Description. Therefore, modifying the structure or ID of parameters, or how data is mapped into the parameters, can potentially cause failures within deployed applications.

Deleted Service Descriptions are unregistered and immediately become unavailable to any applications, deployed or otherwise. It is critical that before deregistering a Service Description, a check is performed to ensure that there are no applications that are using the Service Description.

In general, adding new parameters or mappings and changing names and descriptions does not cause failures. However, removing existing parameters, changing parameter mapping, or modifying IDs for Service Description, Service Transport, or a parameter, are likely to cause failures. A list of potentially safe and unsafe operations are summarized in Table 1.

Table 1. Summary of potentially safe and unsafe changes
Potentially Safe Changes Potentially Unsafe Changes
  • Adding new parameters
  • Changing the name of a parameter
  • Changing the description of a parameter
  • Changing the name of the Service Description
  • Changing the description of the Service Description
  • Adding support for an additional language within the Service Description
  • Changing the Service Description default locale.
  • Removing existing parameters
  • Changing the ID of an existing parameter
  • Changing the ID of the Service Description
  • Changing the Transport ID of the Service Description
  • Changing the mapping of existing parameters.
If significant changes must be made to a Service Description that is in use by deployed applications, a new Service Description must be created and the existing Service Description must remain intact. The new Service Description must be given a unique ID, and given a distinct name with a version number to indicate that this new Service Description is different from similarly named ones.