inteligr8/SearchServices
1
0
Fork 0
mirror of https://github.com/Alfresco/SearchServices.git synced 2025-09-10 14:11:25 +00:00
Code Issues Packages Projects Releases Wiki Activity

Alternative 2 Evaluation

Browse Source
This commit is contained in:
Angel Borroy
2019-04-24 18:28:53 +02:00
parent 69fb170c75
commit 268d819a84
2 changed files with 44 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

BIN
search-services/alfresco-search/doc/architecture/event-trackers/content-tracker-2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 100 KiB

44
search-services/alfresco-search/doc/architecture/event-trackers/event-based-content-tracker-spike.md
View File

@@ -130,3 +130,47 @@ Both source and target files can be deleted from `Shared File Store` after the o
**Consequences**
No consequences for *Search Services* are expected from applying this alternative. Probably then only one is that the whole indexing process will become slower, as the transformation is performed by the new Transform Service and contents are uploaded and downloaded using HTTP protocol. Anyway, this problem can be overcome by providing the right resources to Transform Service.
### 2 - New Microservice in the Middle
Introduce a new microservice that sits between Search Service and the Transformation Service. The content is off loaded to Transformation Service and the microservice stores the content for Search Service to ingest.
![New Microservice in the Middle](content-tracker-2.png)
**Components referenced in the figure**
* [alfresco-search](https://github.com/Alfresco/SearchServices/tree/master/alfresco-search): Alfresco SOLR Application, deployed in SOLR Jetty web application `solr.war` as library
* *DockerSOLR*: New REST API Layer based in Spring Boot App (to be dockerizable) to be designed. This component is also publishing `TransformRequest` events to be consumed by *Transform Service*
* [alfresco-remote-api](https://github.com/Alfresco/alfresco-remote-api): REST API Layer for Alfresco Content Services, deployed in Alfresco Tomcat web application `alfresco.war` as library
* [Shared File Store](https://github.com/Alfresco/alfresco-shared-file-store): REST API Layer to share contents between a *T-Client* and the *T-Engine*
* [T-Service](https://github.com/Alfresco/alfresco-transform-service): Alfresco Transform Service to route JMS Events to T-Engines
* [DockerTika](https://git.alfresco.com/Repository/alfresco-docker-transformers/tree/master/alfresco-docker-tika) REST API Layer for *T-Engine* based in Tika
* [DockerLibreoffice](https://git.alfresco.com/Repository/alfresco-docker-transformers/tree/master/alfresco-docker-libreoffice) REST API Layer for *T-Engine* based in LibreOffice
**Transformation Process**
>> A new microservice, named *DockerSOLR* in the diagram, will handle transformations to text requests from Content Tracker. This service replaces previous `NodeContentGet` web script.
Content Tracker invokes to *Docker SOLR* using HTTP REST API to start the transformation (1).
*Docker SOLR* invokes the repository to retrieve the source content for the node using the Remote API (2) and stores the result in the `Shared File Store` to retrieve the `sourceRef` (3).
After that, *Docker SOLR* creates a new *Transform Request* event to be consumed by *Transform Service* (4).
*Transform Service* uses routing component to find the right *Transform Engine* (Tika, LibreOffice...) and perform the invocation with the `sourceRef` and the target media type (TXT) to the *Transform Engine* (5).
Source Content is retrieved from `Shared File Store` using `sourceRef` (6) and the transformation is performed (7) and the result is stored in the `Shared File Store` to retrieve the `targetRef` (8).
After that, *Transform Engine* creates a new *Transform Reply* event (9) to be consumed by *Docker SOLR*, where the content is retrieved from `Shared File Store` using `targetRef` (10).
As the original request (1) has been paused while performing the transformation, *Docker SOLR* returns the TextContent Stream back and the response is delivered to Content Tracker (11).
Both source and target files can be deleted from `Shared File Store` after the operation ends successfully (12,13).
**Consequences**
* A new dependency from Transform Service version must be included in Search Services compatibility matrix.
* It's required to create a switch in Search Services to use current Content Tracker (based in REST API invocation) or the new Content Tracker (including JMS events), mainly to preserve 5.2 compatibility.
* A new component *DockerSOLR* must be developed. This component is a new *T-Client*, dockerizable and JMS ready. Incoming threads must be paused till the JMS *TransforReply* is consumed, so some logic and control need to be added to current code [7]
* **RISK** Currently Transform Service is not supporting several *T-Clients* for the same *Transform Service*, despite the story is being developed [ATS-208](https://issues.alfresco.com/jira/browse/ATS-208). This will exclude this alternative, as *ACS* is the only *T-Client* supported by now. Also, for a Sharding environment, more than one indexing *T-Client* can be required.