Translation Flow and Integration Improvements
Some improvements and changes are specific to Translation Management and Translation Organizer.
Introducing an External Validation endpoint
The CMS contains your document types (DTDs and catalog) configuration, potentially including specializations. The new endpoint allows to single source that configuration by making them available over a REST endpoint. First use case is to allow SDL TMS and SDL WorldServer to validate xml-based translations before allowing retrieval to the CMS.
It is now possible to validate the XML against the DTD by using a newly created endpoint: the External Validate endpoint accessible at https://ish.example.com/ISHCM/Api/ExternalPreview/Validate with either a GET or a POST call. The endpoint will provide a detailed list of errors.
Removed racing condition that send out content twice
Regarding predictability, translations were requested by sending out translation jobs to the target translation systems. However, in some high volume scenarios some items were requested more than once which results in an increased translation cost. This happened when a content object is part of more than one translation job being prepared for sending out.
The correction is in avoiding the sending race condition. We do this by introducing a lease mechanism (visible in area). Only one Translation Organizer instance can send out a job. Note that scaling out services Translation Builder and Translation Organizer still has benefits for the more often executed preparing, checking and retrieving translation actions.
Before: Parallel sending
Translation Builder grabs a job, breaks it down into topics and checks the status of each topic. If the status turns out to be In Translation, the topic is not passed over and will not be translated. Translation Organizer then sets the status of the topic to In Translation before sending it. There is a probability that a topic (Topic A in this example) is sent at the same time by both Translation Organizer instances.
After: Sequential sending
The status In Translation is checked again just before sending, and topics are sent one at a time. No more double sending.
Improved polling increases throughput
Translation Organizer checks for pending jobs at regular intervals. The interval is configured through jobPollingInterval in TranslationOrganizer.config, the default value is 5 minutes. When a group of smaller jobs is available for processing, this interval could make the global processing longer than it should, as Translation Organizer waits for the end of the interval before it picks up the next job.
Now Translation Organizer automatically checks for an available job whenever a job has been completed, in addition to the regular check after the interval.
Stability improvements for the SDL TMS and SDL WorldServer integration
Whenever the server returns an http 500 error to Translation Organizer - which typically means that the remote system is severely disturbed - during the retrieval phase, the former behavior was to request the user to manually restart the job. Now Translation Organizer automatically retries the job.
Some transmission issues have also been fixed, such as the processing of Logical Identifiers having GUIDs with dots (.) as separators. An issue which was introduced on 2016/12.0.0.
Logging details have been added for a better follow-up of every step of the interaction between Translation Organizer and TMS or WorldServer.