The IntrayTransport prototype has the following initialisation parameters:
|config||Optional||Identifier or XML||res:/etc/IntrayConfig.xml|
Configuration for the Intray transport
An identifier for created logical endpoint, if omitted a unique auto-generated value it will be used.
If included this parameter will mark the endpoint as private and it will not be exposed outside module.
Here is an auto-generated example of how to instantiate an instance of IntrayTransport:
To use IntrayTransport transport you must import the module urn:org:netkernel:tpt:intray:
The IntrayTransport is used to poll a filesystem directory for added files. When new files are detected they are removed from the directory and sent to the transport for processing. After processing they are then saved back into a different directory.
The config parameter must specify the configuration for the Intray transport. It should be a resource of the form...
Where the elements are as follows:
An advanced mode allowing regex matches on the filename with rewrites of the out box filename may be used as an alternative to the file extension filtering.
The following config would match all .txt files beginning foo and write the out box file with filename ending in baa and a new extension .xml
Capturing groups in the regex match may be substituted into the rewrite filename using the conventional $x substitution marker.
If the config parameter is not specified then the Intray Transport will attempt to find a configuration resource (of the same form) from res:/etc/IntrayConfig.xml
The request specified in the configuration must be a declarative request. For each file that is found in the intray an instance of this request will be constructed and issued into the space hosting the Intray endpoint.
To be useful the request needs to relay on the identity of the file resource. It should do this by referencing arg:file - whose reference in the declarative request will be replaced with the file: URI of the intray file.
For example suppose we have a configuration such as...
Here the directory file:/home/pjr/temp/in/ will be monitored for new files. Lets suppose that a file named "hello.txt" is copied to this directory.
Upon discovering the file the Intray transport constructs a new request based on the declarative request template. The reference arg:file is replaced by the full URI of the intray file. So, in this case, the request that is constructed and issued by the Intray would be...
The requested service is responsible for dealing with the file as appropriate. Ultimately it returns a response to the Intray transport. The intray transport SINKs the response as a binary stream to the out tray directory specified. Here a file will be written to:
Finally upon successfully completing the processing, the original intray file is deleted.
The intray transport must always write a response to the out tray and so will always request an IBinaryStreamRepresentation, and will override any user specified representation type in the declarative request.