6

We have a requirement to capture, in workflow, any Translation errors and provide the appropriate redirection of workflow control and/or notifications.

The problem is that the public API for Translation Manager Tridion.TranslationManager.DomainModel does not expose information about the errors that occur while translating.

We have a Tridion Workflow that creates a translation job and suspends an activity, then a Translation Manager plugin resumes such activity when the job is completed. However, the completion of the job might have not been successful (an error occurred) and we need a way to determine what caused the error to act accordingly in the workflow.

With the current API we cannot tell which error took place or what was the cause (or see the stack trace for that matter).

Apparent Reason: The API itself can access such errors internally, however the Members which could potentially expose such information are either internal or within an internal class, hence can't be accessed.(See below)

Possible Solution: One possible solution we've considered (which would require the source to be updated so not ideal ... Tridion Support) ... could be to implement one or multiple public members in the Tridion.TranslationManager.DomainModel.Api.TranslationJob class that exposes such information, something like:

public TranslationJobErrorDocumentCollection Errors
    {
      get
      {
        return this._job.Errors;
      }
    }

Current internal members/classes:

namespace Tridion.TranslationManager.DomainModel
{
internal class TranslationJob
  {
...
public TranslationJobErrorDocumentCollection Errors
    {
      get
      {
        return this._errors;
      }
    }

namespace Tridion.TranslationManager.DomainModel.Api
{
  public class TranslationJob
  {
...
internal Tridion.TranslationManager.DomainModel.TranslationJob InternalTranslationJob
    {
      get
      {
        return this._job;
      }
    }
...

SDL Tridion 2013 SP1 HR1

2 Answers 2

7

Quick note on this one. We were able to grab the error in XML format from the world server response that updates the status of the Translation item.

This XML wasn't useful other than it contained "error" and the description (as displayed in the GUI).

We subsequently parse the description and if we find specific (read RegEx) strings such as "contained no items to translate" then we can branch off the workflow accordingly depending on the expected error resolution path.

Not ideal but seen as our process is

if(error == "is caused as there's nothing to translate")
  { proceed_to_the_next_step() }
else
  { move_workflow_to_activity_to_be_managed_by ( WFLOW_OPS_USER )

it was sufficient.

5

You can get the exception message if you subscribe to the TranslationJob.Error event. But you will then have to store it (if you have a way to find the workflow process instance from the translation job, you could put it into a variable).

You should not expect improvements on the current TM API. It is a few days away from being deprecated. :)

The SDL Web 8 API will provide access to the error details. The Translation Manager UI in SDL Web 8 is build on top of the same API as we expose publically.

2
  • Thanks Lars - I was doubtful with any 'hotfix' to the current API but it's something we wanted to ask Support for all the same (in the event they've had to do this before) - the client hasn't an immediate plan for upgrade but this information has been articulated to them to plant that seed!. I'll post back when we've tried the subscription as this may be just the ticket! thanks Nov 18, 2015 at 15:30
  • Can you tell me which event you are referring to? I tried to subscribe to a "Translation" event and I can't find any... Dec 7, 2015 at 13:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.