Controlling the Use of Directives

Directive	Used to...
admin	Route requests to the handler for the Administrator API. For more information about the Administrator API, see Integration Server Administrator API
default	Route requests to the document handler the Integration Server uses to process DSP pages.
graphql	Execute GraphQL operations, specifically, queries or mutations for GraphQL descriptors.
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.

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).