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.

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]
Parents
  • 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

Reply
  • 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

Children
  • 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

  • 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.

  • Hi,

    I hope it's ok if I ask this here instead of creating a new post, but we are having similar issues.

    We have an application which we developed using the Trados Studio 2019 API that we use to analyze files for translation. But instead of server based TMs, the application uses file based TMs that are stored on the local file system.

    We've now been trying to update this application to the new Trados Studio 2021 API, but we are now running into an issue where the analysis reports are not being generated. The issue seems to be the similar to the one above with the following error message: 

    Unexpected exception when initializing task 'Analyse': Die Übersetzungs-Engine 'sdltm.file:///c:/TradosServer/10.0.2.234/MainTMs/C00001612_de-DE_en-GB_def.sdltm' konnte nicht instanziiert werden.."

    Any idea what could be the cause of this? Since we are not using server based TMs it don't think the System.Net.Http.dll is the issue. Thank you very much for any help, it's very much appreciated.

    Here is the entire exception stack trace:

    <SOAP-ENV:Envelope xmlns:xsi="">www.w3.org/.../XMLSchema-instance" xmlns:xsd="">www.w3.org/.../XMLSchema" xmlns:SOAP-ENC="">schemas.xmlsoap.org/.../" xmlns:SOAP-ENV="">schemas.xmlsoap.org/.../" xmlns:clr="">schemas.microsoft.com/.../1.0" SOAP-ENV:encodingStyle="">schemas.xmlsoap.org/.../">
    <SOAP-ENV:Body>
    <a1:ProjectApiException id="ref-1" xmlns:a1="">schemas.microsoft.com/.../Sdl.ProjectApi, Version=16.0.0.0, Culture=neutral, PublicKeyToken=c28cdb26c445c888">
    <ClassName id="ref-4">Sdl.ProjectApi.ProjectApiException</ClassName>
    <Message id="ref-5">Unexpected exception when initializing task &#39;Analyse&#39;: Die Übersetzungs-Engine &#39;sdltm.file:///c:/TradosServer/10.0.2.234/MainTMs/C00001612_de-DE_en-GB_def.sdltm&#39; konnte nicht instanziiert werden..</Message>
    <Data xsi:null="1"/>
    <InnerException href="#ref-6"/>
    <HelpURL xsi:null="1"/>
    <StackTraceString id="ref-7"> bei Sdl.ProjectApi.Implementation.TaskExecution.ContentProcessingTaskImplementation.InitializeTaskImplementations()
    bei Sdl.ProjectApi.Implementation.TaskExecution.ContentProcessingTaskImplementation.Execute()
    bei Sdl.ProjectApi.Implementation.AutomaticTaskExecuter.Execute()</StackTraceString>
    <RemoteStackTraceString xsi:null="1"/>
    <RemoteStackIndex>0</RemoteStackIndex>
    <ExceptionMethod id="ref-8">8
    InitializeTaskImplementations
    Sdl.ProjectApi.Implementation, Version=16.0.0.0, Culture=neutral, PublicKeyToken=c28cdb26c445c888
    Sdl.ProjectApi.Implementation.TaskExecution.ContentProcessingTaskImplementation
    Void InitializeTaskImplementations()</ExceptionMethod>
    <HResult>-2146233088</HResult>
    <Source id="ref-9">Sdl.ProjectApi.Implementation</Source>
    <WatsonBuckets xsi:null="1"/>
    </a1:ProjectApiException>
    <a3:ProjectAutomationException id="ref-6" xmlns:a3="">schemas.microsoft.com/.../Sdl.ProjectAutomation.Core, Version=16.0.0.0, Culture=neutral, PublicKeyToken=c28cdb26c445c888">
    <ClassName id="ref-10">Sdl.ProjectAutomation.Core.ProjectAutomationException</ClassName>
    <Message id="ref-11">Die Übersetzungs-Engine &#39;sdltm.file:///c:/TradosServer/10.0.2.234/MainTMs/C00001612_de-DE_en-GB_def.sdltm&#39; konnte nicht instanziiert werden.</Message>
    <Data xsi:null="1"/>
    <InnerException href="#ref-12"/>
    <HelpURL xsi:null="1"/>
    <StackTraceString id="ref-13"> bei Sdl.ProjectAutomation.FileBased.Internal.AutomationServerEvents.HandleTranslationProviderException(ITranslationProviderItem translationProviderItem, Exception exception)
    bei Sdl.ProjectApi.Helpers.ProjectCascadeFactory.GetTranslationProviderLanguageDirection(ITranslationProviderItem translationProviderItem, LanguagePair languageDirection, Boolean performUpdate, Boolean refreshCache)
    bei Sdl.ProjectApi.Helpers.ProjectCascadeFactory.CreateProjectCascadeEntries(IList`1 projectCascadeEntryDataList, LanguagePair languagePair, Boolean readOnly, Boolean refreshCache)
    bei Sdl.ProjectApi.Helpers.ProjectCascadeFactory.CreateCascade(ProjectCascadeSettings projectCascadeSettings, Boolean refreshCache)
    bei Sdl.ProjectApi.Helpers.LanguageDirectionHelper.CreateCascade(ILanguageDirection languageDirection, ProjectCascadeEntryDataFilterFunction filter, IComparer`1 sort, Boolean readOnly, Boolean refreshCache)
    bei Sdl.ProjectApi.Helpers.LanguageObjectsCache.&#60;&#62;c__DisplayClass6_0.&#60;GetRecognizers&#62;b__0(String _)
    bei System.Collections.Concurrent.ConcurrentDictionary`2.GetOrAdd(TKey key, Func`2 valueFactory)
    bei Sdl.ProjectApi.Helpers.LanguageObjectsCache.GetRecognizers(ILanguageDirection languageDirection)
    bei Sdl.ProjectApi.AutomaticTasks.Analysis.AnalysisDataCollectorX.CreateAnalysisDataStorage(ILanguageDirection languageDirection, AnalysisTaskSettings analysisSettings, TranslationMemorySettings translationMemorySettings, ILanguageObjectsCache objectsCache)
    bei Sdl.ProjectApi.AutomaticTasks.Analysis.AnalysisDataCollectorX.Initialize(IList`1 files)
    bei Sdl.ProjectApi.AutomaticTasks.Analysis.AnalysisTask.CreateAnalysisDataCollectors()
    bei Sdl.ProjectApi.AutomaticTasks.Analysis.AnalysisTask.InitializeTask(IExecutingAutomaticTask task)
    bei Sdl.ProjectApi.Implementation.TaskExecution.ContentProcessingTaskImplementation.InitializeTaskImplementations()</StackTraceString>
    <RemoteStackTraceString xsi:null="1"/>
    <RemoteStackIndex>0</RemoteStackIndex>
    <ExceptionMethod id="ref-14">8
    HandleTranslationProviderException
    Sdl.ProjectAutomation.FileBased, Version=16.0.0.0, Culture=neutral, PublicKeyToken=c28cdb26c445c888
    Sdl.ProjectAutomation.FileBased.Internal.AutomationServerEvents
    Void HandleTranslationProviderException(Sdl.ProjectApi.ITranslationProviderItem, System.Exception)</ExceptionMethod>
    <HResult>-2146233088</HResult>
    <Source id="ref-15">Sdl.ProjectAutomation.FileBased</Source>
    <WatsonBuckets xsi:null="1"/>
    </a3:ProjectAutomationException>
    <a4:ArgumentNullException id="ref-12" xmlns:a4="">schemas.microsoft.com/.../System">
    <ClassName id="ref-16">System.ArgumentNullException</ClassName>
    <Message id="ref-17">Der Wert darf nicht NULL sein.</Message>
    <Data xsi:null="1"/>
    <InnerException xsi:null="1"/>
    <HelpURL xsi:null="1"/>
    <StackTraceString id="ref-18"> bei System.Activator.CreateInstance(Type type, Boolean nonPublic)
    bei System.Activator.CreateInstance(Type type)
    bei Sdl.Core.PluginFramework.DefaultObjectResolver.CreateObject(Type objectType, XElement attributeElement)
    bei Sdl.Core.PluginFramework.Implementation.Extension.CreateInstance()
    bei Sdl.Core.PluginFramework.ObjectRegistry`2.CreateObjects()
    bei Sdl.LanguagePlatform.TranslationMemoryApi.TranslationProviderManager.GetTranslationProviderFactories()
    bei Sdl.LanguagePlatform.TranslationMemoryApi.TranslationProviderManager.CreateTranslationProvider(Uri translationProviderUri, String translationProviderState, ITranslationProviderCredentialStore credentialStore)
    bei Sdl.ProjectApi.TranslationProviderCache.CreateTranslationProvider(Uri translationProviderUri, String translationProviderState, ITranslationProviderCredentialStore credentialStore)
    bei Sdl.ProjectApi.TranslationProviderCache.GetTranslationProvider(Uri translationProviderUri, String translationProviderState, ITranslationProviderCredentialStore credentialStore, Boolean performUpdate, Boolean refreshCache)
    bei Sdl.ProjectApi.Helpers.ProjectCascadeFactory.GetTranslationProviderLanguageDirection(ITranslationProviderItem translationProviderItem, LanguagePair languageDirection, Boolean performUpdate, Boolean refreshCache)</StackTraceString>
    <RemoteStackTraceString xsi:null="1"/>
    <RemoteStackIndex>0</RemoteStackIndex>
    <ExceptionMethod id="ref-19">8
    CreateInstance
    mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
    System.Activator
    System.Object CreateInstance(System.Type, Boolean)</ExceptionMethod>
    <HResult>-2147467261</HResult>
    <Source id="ref-20">mscorlib</Source>
    <WatsonBuckets xsi:null="1"/>
    <ParamName id="ref-21">type</ParamName>
    </a4:ArgumentNullException>
    </SOAP-ENV:Body>
    </SOAP-ENV:Envelope>

  • Hi ,  I'd try to keep the issues separate to avoid scope creep.

    I'm interested to understand if your team were successful in getting the automation working, given the indications I provided above for the Studio 2019 specific issue?
    If yes, then please close this ticket to confirm that the solution provided worked, so that others may also benefit from it; wdyt?

  • Hi Patrick,

    First of all, thank you very much for the quick answer.

    We've tried following the steps you indicated above, but this did not solve our problem. We still get the same error after referencing System.Net.Http Version 4.3.3 as you mentioned above. We also tried using the newer version 4.3.4, but unfortunately this also didn't help.

  • Hi , sorry to hear this.

    I can confirm that during my tests, I was able to reproduce the same exception message that you received initially; I discovered that the root exception was related to a discrepancy in the version of  System.Net.Http; the solution was to make specific reference to that assembly as opposed to pulling it from the GAC.

    What is the full version of Studio 2019 that you are using in your automation environment?

    Lets try the following:

    • I will prepare and provide your team with the automation sample project that I coded where this is working interrogating your GS 2017 server, against the latest production release of Studio 2019 SR2 CU8 that I have locally.  I will update you via e-mail either later on today or tomorrow morning.
    • Try the test without any other plugins from being loaded with the automation Studio environment, to exclude any external influences (e.g. unknowns)
  • Hi Patrick,

    First of all, thank you for your help!

    It seems like an old Version of the DeepL Translation Provider Plugin was the Problem. After removing all Plugins from our installation of Trados Studio 2021 like you suggested, the analysis seems to work fine.

    Thanks again!

  • 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

  • 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

  • Please create a separate post for this.  We cannot manage never ending threads on multiple topics.  They're also unhelpful for other users.