• State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 12 replies
  • Answers 3 answers
  • Subscribers 5 subscribers
  • Views 7532 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Unexpected exception when initializing task, using server TMs on Groupshare 2017 server. failed to initialize translation engine follows.

Hendrik Striepe

Dear SDL Devs and Community,

we are using the API of the latest Trados Studio 2019 with server based TMs on a GS 17 server and keep running into the following problem.

We have an existing sdlproj project. This project was created based on a project template which had information on Server-TMs on our server URL (gs 2017 server) and uses TMs on this very server. The TMs are thus known by our created project.

We have several occurences in our code of similar error messages. The following stack of exception is produced when calling:

ProjectPackageCreation projectPackage = project.CreateProjectPackage(Guid manualTaskId, string packageName, string comment, ProjectPackageCreationOptions options);

What you will see next are the Exception and InnerExceptions of the ProjectPackageCreation object.

Unexpected exception when initializing task 'Analyse': Die Übersetzungs-Engine 'sdltm.URL/Organization English (US) - French (France)' konnte nicht instanziiert werden..

Sdl.ProjectAutomation.Core.ProjectAutomationException: Unexpected exception when initializing task 'Analyse': Die Übersetzungs-Engine 'sdltm.https://URL/?orgPath=%2FOrganization&tmName=Organization English (US) - French (France)' konnte nicht instanziiert werden.. ---> Sdl.ProjectApi.ProjectApiException: Unexpected exception when initializing task 'Analyse': Die Übersetzungs-Engine 'sdltm.https://URL/?orgPath=%2FOrganization&tmName=Organization English (US) - French (France)' konnte nicht instanziiert werden.. ---> Sdl.ProjectAutomation.Core.ProjectAutomationException: Die Übersetzungs-Engine 'sdltm.https://URL/?orgPath=%2FOrganization&tmName=Organization English (US) - French (France)' konnte nicht instanziiert werden. ---> System.Collections.Generic.KeyNotFoundException: No identity information found for server 'https://URL/'.
bei Sdl.Enterprise2.Studio.Platform.Client.IdentityModel.IdentityInfoCache.ValidateKey(String key)
bei Sdl.Enterprise2.Studio.Platform.Client.IdentityModel.IdentityInfoCache.GetIdentityInfo(String key)
bei Sdl.LanguagePlatform.TranslationMemoryApi.IdentityInfoCacheCredentialStore.GetCredential(Uri uri)
bei Sdl.LanguagePlatform.TranslationMemoryApi.TranslationProviderCredentialStore.GetCredential(Uri uri)
bei Sdl.LanguagePlatform.TranslationMemoryApi.ServerBasedTranslationMemoryFactory.GetUserCredentials(Uri translationProviderUri, ITranslationProviderCredentialStore credentialStore)
bei Sdl.LanguagePlatform.TranslationMemoryApi.ServerBasedTranslationMemoryFactory.CreateTranslationProvider(Uri translationProviderUri, String translationProviderState, ITranslationProviderCredentialStore credentialStore)

In preparation of the project package creation step, we try to make sure, that the TMs are available to the project as follows:

string credentials = "user=" + tmServer.username + ";password=" + tmServer.password + ";type=CustomUser";
project.Credentials.AddCredential(strTmUri, credentials);
project.UpdateTranslationProviderConfiguration(tmConfig);
project.Save();

with strTmUri being similar to this: 'sdltm.URL/ English (US) - German (Germany)'

It seems to us, that somehow the login credentials, URL, TM name or a combination of these is wrong. Since we basically are using the demo code from several SDL sources (see links below) it would be great, if you could point out other potential sources of error.

Our project is huge, new, and does work as expected in general but does not really cooperate well with server based TMs on the GS server. We tried to apply everything the docu states @ http://producthelp.sdl.com/SDK/TranslationMemoryApi/2017/html/50a524b7-e3fe-4ba6-894b-b3959fd3f8ce.htm and of course in the projectautomation API part. Further clarification on your side would be greatly appreciated.

Best regards,

Hendrik, on behalf of the Plunet CAT integration team

We already used these resources describing similar problems and TM handling:

https://community.sdl.com/developers-more/developers/language-developers/f/api_qa_-_sdl_tms/12877/how-to-use-analyzefiles-pretranslate-tasks-with-server-based-translation-memory

https://community.sdl.com/developers-more/developers/language-developers/f/sdk_qa/1013/analyzefiles-and-pretranslatefilestasks-inproject-automation-api-ignore-server-tms

https://gist.github.com/cromica/e1a976fdfdc821136c7610b5e984904e

https://github.com/sdl/trados-studio-api-samples/tree/master/LanguagePlatform/Sdl.SDK.LanguagePlatform.Samples.TmAutomation

http://producthelp.sdl.com/SDK/TranslationMemoryApi/3.0/html/646950ef-d135-46dd-a2cf-1c4ebf57ec94.htm


[locked by: Paul at 7:24 AM (GMT 1) on 29 Apr 2021]
Rate translation
×
Suggest better translation
×
Parents
  • 0

    Hi Guys,

    I have investigated this issue this morning and identified the root cause.  It seems that there is an issue in resolving the correct version of System.Net.Http assembly; the original exception is getting gobbled up with abstraction, which was preventing us from understanding the root cause in this case.

    You can work around this by simply making a hard reference to the same version of this assembly (that Studio 2019 is using) in your automation project.

    Add this reference to your project: C:\Program Files (x86)\SDL\SDL Trados Studio\Studio15\System.Net.Http.dll
  • 0 in reply to Patrick Andrew Hartnett

    Hi Patrick,

    thank you very much for having a look at our problems here. We compiled a few questions that came up when trying to use your suggested fix:

     

    1. @ Server-TM 8 hour bug:
      1. Is there a difference between both the ProjectCredentials.AddCredential methods? http://producthelp.sdl.com/SDK/BatchTaskApi/1.0/html/05e5f07c-6ff5-8afe-9617-7756003375d5.htm - we are using this:
        string credentials = "user=" + tmServer.username + ";password=" + tmServer.password + ";type=CustomUser";
        Does this behave similarly to your suggestion, when adding GS 2017 / 2021 server TMs?
        project.Credentials.AddCredential(new Uri(serverAddress), false, name, password);
      2. Can we assume, that our code will connect to the groupshare server with a new token / login instance ( or however that is managed inside the API)?
        Or is there a possibility of the Studio API somewhere holding - and after time devaluating - login tokens over several login attempts, if the credentials are the same, in some sort of buffered way?
        Our code basically does this:
        • creating or loading FileBasedProject, which references a sdlproj-Template containing GS-Server-TM in one or more target languages.
        • Then before AutomaticTaskTemplateIds.AnalyzeFiles / PreTranslateFiles / UpdateMainTranslationMemories / PopulateProjectTranslationMemories and project.CreateProjectPackage :
        • Add Credentials for known ServerTMs (inside the project) to the project with project.Credentials.AddCredential
    1. Net.Http.dll:
      1. Thank you for your suggestion to
        Add this reference to your project: C:\Program Files (x86)\SDL\SDL Trados Studio\Studio15\System.Net.Http.dll
      2. But unfortunately our Studio 2019 installation, versioned 15.2.8.3007, which is untouched so far, does not contain that dll. Neither does Studio 2021 16.1.3.4096.
      3. Which version of the .net framework are you using when developing Studio API code? Possibly we are referencing the wrong version of .net which includes the wrong version of System.Net.Http.dll
      4. Do we have to include that dll manually, e.g. with Nuget? Which version of the dll do you suggest downloading? The newest version available would be 4.3.4, but in our experience, nuget versions should match the versions used by Trados Studio (e.g. Newtonsoft.Json).
      5. If we install the dll on our own, does the .Net dll lookup make sure to look first in the Studio2015 folder, even when using your precompiled API, which implicitely uses System.net.HTTP?

     

    Hopefully you will be able to make use of our problem description, otherwise don’t hesitate to contact me directly.

    Best,

    Hendrik
  • 0 in reply to Hendrik Striepe

    Hi Hendrik,

    Sorry to hear you are still having problems in getting this running on your system. You are right, my mistake, that dll doesn't seem to be included with the installer anymore.

    1. There should be no difference with choosing one overload over the other for ProjectCredentials.AddCredential.

    2. I have just checked now and the version of System.Net.Http that I’m using locally for Studio 2019 is 4.3.3, available for download here  https://www.nuget.org/packages/System.Net.Http/4.3.3
    Download/extract and make a hard reference to the \runtimes\win\lib\net46\System.Net.Http.dll from that package

    let me know how it goes,

    P.
  • 0 in reply to Patrick Andrew Hartnett

    Hi Patrick,

    unfortunately the message

    Unexpected exception when configuring file multiFileConverter for task 'Übersetzte Wörter zählen': Die Übersetzungs-Engine 'sdltm.GROUPSHARESRV Resources%2FO-00133 English (USA) 020&tmName=Testing' konnte nicht instanziiert werden..

    is still bugging our customer and us when using Trados 2019 with GS 2017, although we added the dependency to system.http.

    The Groupshare server in its TMService.log seems to log this error which should be related:

    2021-04-21 08:04:37.2402|GROUPSHARESRV|Warn|THREAD_ID:22|TR_ID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx|Authentication failed: The message expired at 20.04.2021 19:39:44 and it is now 21.04.2021 08:04:37.
    2021-04-21 08:04:37.2402|GROUPSHARESRV|Warn|THREAD_ID:22|TR_ID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx|Unauthorized request

    Since this seems to be a Groupshare problem, we thought about possibly sending a keep alive to the GS 2017 server, possibly requesting login tokens on a regular basis (x hours) or before using actual server TMs.

    Do you think this might solve the problem or would this be a waste of time?

    Do you have other suggestions, e.g. another method of accessing server TMs within the Studio API, or other tools ( https://github.com/sdl/groupsharekit.net )?

    We need code that works together with the project automation API since we rely on project.runautomatictask to achieve CAT business.

    Our server TM access code is still the same as in the original post.

    Best regards,

    Hendrik
  • 0 in reply to Hendrik Striepe

    Hi ,

    we managed to recreate a similar error, when logging into GS2017 via Postman. The Bearer-Token is invalidated after 12 hours. When we try to login with the same token the next day, we get exactly the same error Message in TMService.log:

    2021-04-28 15:00:59.1643|OURSERVER|Warn|THREAD_ID:35|TR_ID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx|Authentication failed: The message expired at 28.04.2021 03:22:25 and it is now 28.04.2021 15:00:59.

    2021-04-28 15:00:59.1643|OURSERVER|Warn|THREAD_ID:35|TR_ID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx|Unauthorized request

    It seems, that the Trados Studio 2019 API does not refresh the Bearer Token if necessary.

    The only method of accessing the GS2017 within our code was, to set FileBasedProject.AddCredentials for our TMs.

    Is there a way to tell the API that it should refresh the token?

    Is there another way of accessing TMs that does not fail after 12 hours?

    Is it possible to fix this?

    Best regards,

    Hendrik
Reply
  • 0 in reply to Hendrik Striepe

    Hi ,

    we managed to recreate a similar error, when logging into GS2017 via Postman. The Bearer-Token is invalidated after 12 hours. When we try to login with the same token the next day, we get exactly the same error Message in TMService.log:

    2021-04-28 15:00:59.1643|OURSERVER|Warn|THREAD_ID:35|TR_ID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx|Authentication failed: The message expired at 28.04.2021 03:22:25 and it is now 28.04.2021 15:00:59.

    2021-04-28 15:00:59.1643|OURSERVER|Warn|THREAD_ID:35|TR_ID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx|Unauthorized request

    It seems, that the Trados Studio 2019 API does not refresh the Bearer Token if necessary.

    The only method of accessing the GS2017 within our code was, to set FileBasedProject.AddCredentials for our TMs.

    Is there a way to tell the API that it should refresh the token?

    Is there another way of accessing TMs that does not fail after 12 hours?

    Is it possible to fix this?

    Best regards,

    Hendrik
Children