Due to its streaming mode, ARender must keep an access to the document content during all the viewing lifespan.
But it comes a time when the document cache expires and the currently opened document is longer viewable.
Historically, UUID-based identifiers types were used for identifying documents, using upstream Ids (i.e. Document Ids in the ECM system) to generate unique numbers. Although this method is great to grant uniqueness, it does not allow to recompute the original (upstream) Id from the ARender Id. As such, it is to be considered as a security feature : the end-user is not able to known upstream Id from the Id used in ARender.
The trick is to generate identifiers which contain all information which are necessary to retrieve the document content, using a kind of bijective function.
When a user calls ARender for document viewing, the original URL contains all the data required for ARender to fetch document content upstream.
The sequence is as follows :
- Generation of a unique self-contained id from the data provided in the original URL
- Content fetching from upstream provider
- Visualization to the end-user,
After a defined duration, the document is flushed out of cache, but whenever the user continues to visualize the document (fetching new pages, …):
- The document is not found in the cache
- The id of the document is parsed and its identification information are retrieved
- The content is asynchronously fetched again via the right connector
- Visualization can be resumed
In order to use this new feature, each connector has at its disposal a dedicated Factory, DocumentIdFactory, which exposes the following method:
DocumentId generate(List<DocumentIdParameter> parameters);
Then, it is the responsability of each connector to provide a list of parameters (key/value(s)) allowing unique and reversible document identification.
Nota: For security reasons, this feature can be disabled. So, UUIDs will be generated.