Controlling the Use of Directives
A directive is a way to access or invoke resources. Integration Server supports these directives:
Directive | Used to |
admin | |
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. |
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).