Page: Initializing a Custom Module
Page: Working With the Request
Page: Getting Request Path Parameters
Page: Creating an Output Message
Page: HTTP Module
Page: Getting HTTP Query String Parameters
Page: Getting HTTP Headers
Page: Getting the Module Directive
Page: Getting Route Parameters
Page: Accessing the Message Body in a Route
Page: Triggering Push Requests in a Route
Initializing a Custom Module
When initializing a custom module, you should be aware of the available properties, as well as the situations in which a new instance of a module is created. This section describes the following topics:
Modules are server-side components that are invoked by the Akula server during the processing of a route.
When the Akula server first starts, all modules are instantiated and loaded into memory. For example, a route that contains the following module element creates an instance of the SimpleModule when the server starts:
Subsequent requests that invoke the same route use the existing instance of that module.
If the same route uses the same module multiple times, Akula creates a new instance of the module for each time it appears in the route. For example, the following route creates three instances of the SimpleModule:
If multiple routes use the same module, Akula also creates a new instance of the module for each route. For example, the following routes use the same instance of the SimpleModule:
In this case, Akula creates a new instance of the SimpleModule for each route.
When using instance properties on a custom module, be aware that Akula re-uses the same instance of a module for each request in the same route. As a result, if you set the value of an instance property on a custom module, this value will be used by all requests to that route.
As described in Creating a Simple Module, Akula invokes the custom module's
init() method only once per instance of the module. As a result, when setting the value of instance properties in the
init() method, you should only set properties that should be shared across all requests that use that route.
Route properties are set by the route developer in the route configuration file. These properties are typically set once for the route and then used during initialization of a custom module.
The route developer can define the following properties in the route configuration file:
- URI – (Required in route definition) The URI of the module. You use the
getUri()method to access this value.
- Directive – (Required) The string that comes after the
prefix://in the module's definition. You use the AKRouteParameter class's
getRemaining()method to access this value.
- Route properties – (Optional) Name/value pairs that appear after the directive in the module definition. You use the
getRouteProperties()methods of the AKRouteParameters class to access these values.
The following syntax shows where these values are set in a typical module definition within the route configuration file:
The following example route configuration sets two route properties,
targetContentType. In this example, "Convert" is the directive, and the entire string is the URI.
The client app developer can set properties on the request that can be used in a custom module. These properties are read-only and provide information about the request. They are accessed via the AKRequest object. For example, a data access request takes the form of a URI, which looks like the following:
- Request path parameters – Values entered in the HTTP request URL and processed by the endpoint. For example, if a client requests the above URL, and the endpoint definition assigns the value with a macro, then you can access that value in your module. For more information, see Getting Request Path Parameters .
Query string parameters – Parameters set on the HTTP request URL that the client used to make a data request. For more information, see Getting HTTP Query String Parameters .
- Request headers – Headers in the initial HTTP request. The HTTP headers are not explicitly defined in the URL, but are set by the client app. For information on accessing the headers in a custom module, see Getting HTTP Headers .
For more information about how client applications can set request properties such as HTTP headers and query string parameters, see Remote Data Access from Android and iOS Clients.
App administrators set properties on an app scope by using properties files in the Akula project. These properties are typically set once by the administrator and are read in the custom module for initialization. You can access these app properties in a custom module by using the
You can get and set properties within a custom module on the AKExchange object. Because this object manages the input and output messages through a route, all modules in a route can access these properties.
To use the exchange properties, use the
setProperty() methods of the AKExchange object. For more information, see Using Exchange Properties in a Custom Module.
For more information on initializing a custom module, see the following topics: