Is Semantria a real-time solution?
The Semantria API isn’t a real-time solution. However, it’s designed for high loading and it’s optimized for processing a large number of incoming tasks. Not real-time means that when a request is made, the task becomes queued for processing. Processing goes fast, however it is extremely dependent on service loading. By default, the service collects tasks and runs processing every 30-60 seconds. If the service is overloaded the delay may be higher but it will never exceed 5
How I can get the processed results back?
The Semantria API has several options available for retrieving data. Depending on the customer’s needs, the service may be configured for results responding on every data queuing call, or the customer may request to process results manually. Retrieval of the tasks one by one is the worst scenario that uses up calls. The Auto response feature is designed for analyzing thousands of records in a short amount of time (1-2 hours). It allows customers to get their tasks in real-time while queuing new tasks. If the auto response option is switched on, the service responds with a limited number of already processed tasks. By default, the server may respond with 2 processed tasks for each incoming data request. However, this limit can be configured. Even with the default limit of 2 processed tasks, customers will receive the processed results two times faster than when queuing them.
Requesting results manually allows the customer to call the service at any time and get up to a configured number of processed tasks in one call. By default, it’s limited to 100 tasks per call. This number can be configured according to the customer’s needs. So there will be two jobs running simultaneously, one for data queuing and another for data retrieval. With the manual data retrieval method, there will be some delay, as previously mentioned above.
The third option is to request a queued task by its ID. Similar to the other options, processed results will be available after some delay. Retrieving the task by its ID allows customers to verify the current task status. The service will respond with processed results if the responded status is PROCESSED. The other possible statuses are QUEUED, IN_SERVICE or FAILED.