Published Service Properties

In the Policy Manager, all your web services and XML applications are listed under the list of Services and Properties. A different icon is used for each to help you quickly identify each:
In the Policy Manager, all your web services and XML applications are listed under the list of Services and Properties. A different icon is used for each to help you quickly identify each:
Gear_icon.png icon = Web service
XMLObject16.gif icon = XML application
For the first instance, the Web Start Policy Manager takes more time to open the Service Properties window of a SOAP service.
Access the properties of a service to do the following tasks:
  • Disable or enable a service
  • Changing the service name
  • Set a resolution URI
  • Specifying the allowed HTTP methods
  • View or reset the service WSDL
The Policy Manager differentiates between SOAP web services and XML or non-SOAP applications. Collectively referred to as "services", each requires a different publication wizard:
The term
identity
includes both users and groups; user can represent an individual human or machine; service includes both web services and XML applications.
Both web services and XML applications appear in the Services and Policies List list upon publication. Security policies for the services are configured in the policy development window.
Supporting JMS Requests
If a service supports JMS requests, ensure that the WSDL for the service specifies unique values for the following attributes:
SOAP payload namespace URI (i.e., child elements of SOAP:Body)
SOAPAction
Note that an empty string "" is considered a value.
As messages received over JMS cannot be resolved using an HTTP resolution URI, they rely on a unique combination of payload namespace URI and SOAPAction. In practice, this means the Gateway cannot resolve JMS messages if multiple services have been published using identical WSDL documents.
In rare instances, similar but not identical WSDL documents may prevent JMS messages from being resolved. Specifically, the Gateway allows two services to be published using WSDLs that have the same SOAP payload namespace URI, but with different SOAPAction values. In this scenario, JMS requests do not resolve to any service unless the following conditions are met:
  • The inbound JMS queues are configured with a SOAPAction attribute. Do this by setting the “Use JMS message property as SOAPAction in service resolution” setting in Manage JMS Destinations.
  • The inbound JMS requests contain valid values in that attribute
To access the properties for a service:
  • Do either of the following:
    • Right-click the web service or XML application under the Services and Policies list and then select
      Properties
      .
    • Select [
      File
      ] >
      Service Properties
      from the Main Menu.
      The Published Service Properties are displayed. This dialog organizes the service properties of these tabs: General, HTTP/FTP, and WSDL.
      All controls in the Published Service Properties are disabled if any of the following applies:
      - You do not have permission to edit service properties ("Manage [name] Service" role), OR
      - If the policy for the service is currently being edited and there are unsaved changes. This is indicated by the message "Service has unsaved policy changes" next to the [OK] button in the properties dialog).
Configuring the [General] Tab
The [General] tab contains basic information about the service, including settings to disable/enable the service.
Setting
Description
Service Display Name
The name of the service as it appears in the services and policies list and in the policy tabs. You can change this name if necessary.
Service ID
The entity ID for the published service. This value is for displayed for reference only and cannot be modified.
Policy GUID
The GUID for the policy. This value is for displayed for reference only and cannot be modified.
Perform WS-Security processing for this service
Select this check box to perform WS-Security processing for the published service. By default, this is not enabled for XML services but is enabled for all other services.
(1) The Gateway performs WS-Security processing on a request message as required by the services policy, even if [Perform WS-Security processing for this service] is not selected. This allows assertions that require WS-Security processing on request messages to run, even when WS-Security processing is disabled in a service. (2) If there are WS-Security assertions in an XML service, be sure to enable WS-Security processing, otherwise these assertions do not work.
Additional Properties
Optionally define additional properties for the service.
Note:
Your administrator can help you determine the need for additional properties.
  • To add an additional property, click [
    Add
    ] and then enter the
    Name
    and
    Value
    .
  • To modify a property in the list, select the row and then click [
    Edit
    ]. Edit the
    Name
    or
    Value
    as required.
  • To remove a property from the list, select the row and then click [
    Remove
    ].
Enable
Select this option to enable a service that has been disabled. When enabled, the red "X" over the icon is removed and the service accepts requests. By default, all services are enabled after publication, except for those services created using the Create WSDL Wizard.
Disable
Select this option to disable a service. All requests for a disabled service are rejected. When disabled, a red "X" appears over the icon and the service refuses all requests. Disabling is a good alternative to deleting a service.
Enable policy debug tracing
Select this option to enable tracing of policy execution for the current service. This may help you debug problems in your policy. When tracing is enabled, a green "bug" icon appears over the service icon. For more information, see "Policy Debug Tracing" under Debug a Policy.
(1) Enabling debug tracing creates a debug trace policy, if one does not exist yet. Disabling debug tracing does not remove the debug trace policy. (2) You can optionally allow the trace to inspect the backing policy of an encapsulated assertion.
WARNING:
Only use policy debug tracing for troubleshooting purposes, as it degrades policy performance significantly.
Security Zone
Optionally choose a security zone. To remove this entity from a security zone (security role permitting), choose "No security zone".
For more information about security zones, see Understanding Security Zones.
This control is hidden if either: (a) no security zones have been defined, or (b) you do not have Read access to any security zone (regardless of whether you have Read access to entities inside the zones).
If you are updating a service, you can only choose zones to which you are permitted to update services.
Configuring the [HTTP/FTP] Tab
The [HTTP/FTP] tab contains service resolution settings for both HTTP and FTP protocols and the HTTP methods permitted.
Setting
Description
Service Resolution
Use this section to view or change the resolution path for a service.
  • No resolution path:
    (Applies to web services only) Select this option to set the resolution path to the default Gateway URI "/ssg/soap".
  • Custom resolution path:
    Select this option to enter a custom resolution URI for the service. A custom resolution path is mandatory for XML applications, but optional for web services. The Custom resolution path cannot begin with "/ssg".
For more information, see "About the Resolution Path" at the end of this topic.
(1) Only enter a path that completes the embedded Gateway URL into the field—make sure that it does not duplicate any other Gateway resolution paths. You may include the '*' (asterisk) wildcard in the path to allow for any incoming URL following a certain pattern to resolve to this service. For details on how the wildcards are interpreted, see Validate Against Swagger Document Assertion will be used, the service resolution URI must end with '
/*
' (no quotes), otherwise the service cannot be resolved.
[Check for resolution conflicts]
Click this button to check whether the service is resolvable via HTTP/FTP and which other services have resolution conflicts with this service. If conflicting services are displayed, enter a different Custom resolution path and then check again.
If there are no issues with the resolution path, you see the message "No Conflicts. The service resolves successfully."
Allowable HTTP Methods
Select which HTTP methods are permitted for incoming requests. The Gateway supports these verbs: GET, PUT, POST, DELETE, HEAD, PATCH, OPTIONS.Select Other to allow any HTTP method name not already listed above.
By default, SOAP web services accept only POST requests, while non-SOAP applications support GET, PUT, POST, DELETE. If you do not select a HTTP method, the service is not accessible through HTTP. However, it could still allow access through non-HTTP transport methods (for example, JMS, FTP, SSH, or email).
WARNING:
Use the "Other" option with care, as it can permit any arbitrary string in the incoming request. Be sure to validate the method name in policy, using the
${request.http.method}
context variable. You can also place the validation the service policy or in a 'message-complete' global policy fragment.
Configuring the [WSDL] Tab
The [WSDL] tab displays the WSDL document for a published web service. Scroll through the window to examine the WSDL. You can also right-click within the WSDL window to do the following:
  • Search the WSDL:
    Select
    Search a node
    from the context menu to jump to a specific node within the WSDL.
  • Copy lines from the WSDL:
    Select
    Copy
    from the context menu to copy the selected lines from the WSDL. You can then paste these lines as text in another application.
The [WSDL] tab is available only for SOAP web services.
Setting
Description
Reset WSDL
You can change the WSDL for a published web service with another WSDL document. Once reset, the existing policy becomes active for the resolution parameters extracted from the new WSDL document.
For more information, see Resetting the WSDL for a Service.
Edit WSDL
You can modify the existing WSDL document for the service by clicking [Edit WSDL]. This opens the Edit WSDL Wizard, which leads you through the editing process. The wizard is prepopulated with the contents of the WSDL document. You can add or remove operations by following the wizard.
SOAP version
Select the SOAP version to be supported by the service:
SOAP 1.1
SOAP 1.2
Unspecified (
either SOAP version is accepted)
When a service is first published, the initial SOAP version is based on the bindings that are present in the WSDL, in the order in which they appear.
Allow requests intended for operations not supported by the WSDL
By default, the Gateway only permits SOAP requests for operations supported by the service's WSDL. If you need to override this behavior for the selected web service, select the [Allow requests intended for operations that are not supported by the WSDL] check box.
Select this check box only if you need to do any of the following:
  • Allow SOAP messages that are not explicitly supported in the WSDL.
  • Allow non-SOAP messages to be sent to a SOAP service.
  • Allow encryption of the Body element in the SOAP request to pass through the Gateway (for example, if the Gateway is unable to decrypt the contents of the Body element).
  • Bypass the SOAP version check (e.g., allows a SOAP 1.1 request to be sent to a service marked as SOAP 1.2, although warning messages continue to appear about incompatible XPath namespaces).
To learn more about how the Gateway resolves a request, see Gateway Service Resolution Process.
Specify a custom resolution path (in the [HTTP] tab) if you are enabling the "Allow requests intended for..." feature. Otherwise, a request could fail under the following conditions:
  • A service uses distinct SOAPAction values in its operations, AND
  • A request arrives with a SOAPAction value that is not supported by the service's WSDL.
A custom resolution path is optional if the WSDL for a service does not specify any SOAPAction values or uses the same SOAPAction value for all operations.
About the Resolution Path
A resolution path must be specified when a web service is published. If a custom resolution path was not specified, the default URI "/ssg/soap" is used and only requests directed to this URI are consumed. Should you attempt to republish the same web service, you must specify a different resolution path to differentiate between the two services.
When an XML application is published, specifying a custom resolution path is mandatory. Some resolution paths are reserved for internal use. If you enter a custom resolution path that conflicts with an internal one, you see a warning message.
The custom resolution path can be entered using the Publish SOAP Web Service Wizard and can be entered, changed, or removed using the Service Properties ([HTTP/FTP] tab). It is displayed in the Services and Policies list next to the service name. For example, the name appears as "ServiceName [/customPath]" instead of simply "ServiceName".
For information on how the Gateway resolves the destination web service, see Gateway Service Resolution Process.
(1) The resolution path for published services applies to both HTTP and FTP-based transports. This allows (for example) consumption of non-SOAP traffic over FTP, multiple versions of the same service consumed over FTP. (2) Since the default service resolution process uses SOAP payload namespace URI and SOAPAction values, customizing the resolution path of a web service allows the same WSDL to be published more than once. Without a customized resolution path, duplication would result in runtime ambiguity.