Trading Networks 10.3 | Administering and Monitoring B2B Transactions | Integration Server Administrator's Guide | Controlling Access to Resources | Controlling the Use of Directives
 
Controlling the Use of Directives
A directive is a way to access or invoke resources. Integration Server supports these directives:
Directive
Used to...
default
Route requests to the document handler the Integration Server uses to process DSP pages.
invoke
Run services.
odata
Process incoming OData service requests.
rad
Perform service invocations submitted as REST requests where the REST resources are configured using the URL template-based approach and must be exposed as REST API using the REST API descriptor. For more information about the approaches for configuring restv2 resources, see REST Developer’s Guide.
Note:
It is recommended to use rad directive for the restv2 resources.
rest
Perform service invocations submitted as REST requests where the REST resources are configured using the legacy approach. For more information about the approaches for configuring REST resources, see REST Developer’s Guide.
restv2
Perform service invocations submitted as REST requests where the REST resources are configured using the URL template-based approach. For more information about the approaches for configuring restv2 resources, see REST Developer’s Guide.
soap
Route requests to the Integration Server SOAP message handler.
Note:
The soap directive is deprecated.
The SOAP message handler routes messages to SOAP processors provided in versions of Integration Server prior to version 7.1.2. These processors have since been deprecated. The SOAP message handler also provides support for web services developed in Integration Server version 6.5.
web
Access JSP files.
ws
Invoke web services, specifically, operations in provider web service descriptors.
Users specify directives as follows:
http://host:port/directive/interface/service_name
For example:
http://localhost:5555/invoke/wm.server/ping
By default, all Integration Server ports except the proxy port allow all the directives listed above. The proxy port allows all directives except the web directive. However, for security reasons, an organization typically allows only those directives that are necessary to fulfill its business requirements. You might allow all directives on ports that are accessible only to users within your firewall, but you might want to restrict directives on ports that are exposed to users outside the firewall. For example, if you want to receive only SOAP requests on a particular port, from both internal and external users, you could allow the soap directive but no other directives on that port. To restrict the use of directives to certain ports only, you set the watt.server.allowDirective parameter (see watt.server.).
You can specify alternative names for the invoke, soap, and rest directives. For example, by default, the invoke directive is specified on URLs as "invoke" (that is, http://host:port/invoke/folder/service_name). You can identify an alternative word for users to specify as the invoke directive. For example, you might want to allow users to specify the invoke directive as "submit" (that is, http://host:port/submit/folder/service_name).
To specify an alternative word for the invoke directive, set the watt.server.invokeDirective parameter (see Server Configuration Parameters).
To specify an alternative word for the soap directive, set the watt.server.SOAP.directive parameter (see Server Configuration Parameters).
To specify an alternative word for the rest directive, set the watt.server.RESTDirective parameter (see Server Configuration Parameters).
To specify an alternative word for the restv2 directive, set the watt.server.RESTDirective.V2 parameter (see Server Configuration Parameters).