• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 4 subscribers
  • Views 3377 views
  • Users 0 members are here
Options
Related

Trados Studio 2019 API, FileBasedProject + Groupshare -> Expired token, unexpected exception, could not instantiate translation engine.

Hendrik Striepe

Dear SDL Devs, dear community,

we are currently running into the following issue:

Our Code uses an existing FileBasedProject. When updating the project credentials or TM settings we get the following exception:

Die Übersetzungs-Engine 'sdltm.groupshare.OURURL.com/ (US) - German (Germany)' konnte nicht instanziiert werden..

TMService.log shows the following problem:

2019-09-02 14:09:00.1913|SDLGROUPSHARE|Warn|THREAD_ID:23|TR_ID:OURIDHERE|Unauthorized request
2019-09-02 14:09:00.2382|SDLGROUPSHARE|Warn|THREAD_ID:23|TR_ID:ANOTHERIDHERE|Authentication failed: The message expired at 30.08.2019 10:46:44 and it is now 02.09.2019 14:09:00.

SDL Application.log shows the following problem:

2019-09-02 14:12:15.726#SecurityHandler.OAuthTokenHandler#DotNetOpenAuth.Messaging.ProtocolFaultResponseException: The message expired at 27.07.2019 01:56:48 and it is now 02.09.2019 14:12:15. ---> DotNetOpenAuth.Messaging.Bindings.ExpiredMessageException: The message expired at 27.07.2019 01:56:48 and it is now 02.09.2019 14:12:15.
bei DotNetOpenAuth.OAuth2.AccessToken.EnsureValidMessage()
bei DotNetOpenAuth.Messaging.DataBag.DotNetOpenAuth.Messaging.IMessage.EnsureValidMessage()
bei DotNetOpenAuth.Messaging.MessageSerializer.Deserialize(IDictionary`2 fields, MessageDictionary messageDictionary)
bei DotNetOpenAuth.Messaging.UriStyleMessageFormatter`1.DeserializeCore(T message, Byte[] data)
bei DotNetOpenAuth.Messaging.DataBagFormatterBase`1.Deserialize(T message, String value, IProtocolMessage containingMessage, String messagePartName)
bei DotNetOpenAuth.OAuth2.StandardAccessTokenAnalyzer.DeserializeAccessToken(IDirectedProtocolMessage message, String accessToken)
bei DotNetOpenAuth.OAuth2.ResourceServer.GetAccessToken(HttpRequestBase httpRequestInfo, String[] requiredScopes)
--- Ende der internen Ausnahmestapelüberwachung ---
bei DotNetOpenAuth.OAuth2.ResourceServer.GetAccessToken(HttpRequestBase httpRequestInfo, String[] requiredScopes)
bei DotNetOpenAuth.OAuth2.ResourceServer.GetAccessToken(HttpRequestMessage request, String[] requiredScopes)
bei Sdl.StudioServer.Authorization.SecurityHandler.OAuthTokenHandler.SetThreadIdentity(HttpRequestMessage request)

The token seems to expire after 12 hours, but we did not measure the exact amount of time.

  1. Can you check if we run into the same problem (expiring tokens) that was discussed previously here: https://gateway.sdl.com/apex/communityknowledge?articleName=000006236 ?
  2. Do you have any other suggestions that we can try, besides following the instructions from https://gist.github.com/cromica/e1a976fdfdc821136c7610b5e984904e (we checked already for code similarity)?
  3. At the moment it's not feasible for us to use https://github.com/sdl/groupsharekit.net since we have a huge code base, so refactoring to GS kit would be quite an effort.

Best regards from Würzburg, Germany,

Hendrik

We work with FileBasesProject based on Project Automation API in Trados Studio 2019 SR 2 15.2.0.1041.

We use Groupshare-based TMs on our own hosted Groupshare-Server running UI: 14.1.10 GS: 14.2.60175.10 - SR1 CU10.
Rate translation
×
Suggest better translation
×
  • 0

    Short update on this issue: It was possible to narrow down the problem. We used a template with specific language pairs and added the Groupshare-based TMs to each respective language pair before. The error occurs.

    But if we add our GS-based TMs to "all languages" in the project template, we don't receive the error described. Does this make sense to anybody?
  • 0

    Would it be possible to send me a sample application and project where the problem is appearing? If don't want to share them in the community you can write them directly on my email rocrisan@sdl.com

    Also can you please let me know what type of authentication you are using on the GS instance?

    Romulus Crisan | Translation Productivity Development Manager | SDL | (twitter) @cromica_82 | (blog) http://www.romuluscrisan.com/

  • 0 in reply to Romulus Crisan (former member)

    Hi is there any update on this issue? We have exactly same message in our automation. thank you,

     Fana
  • +1

    Hi , 

    I have been reviewing this issue during the last days and confirm that I was eventually successful in reproducing the exception that you mentioned, but only once.

    Note: I couldn’t identify anything that is incorrect from the code changes that you applied with your version of the automation app, apart from the multiple attempts to save the project, which isn’t necessary for the tests performed.   In all cases, it is unlikely that the multiple attempts to save the project is the cause of the exception, as it occurs further up the stack.

    Test-case setup:

    • Imported the TM resources that you provided on a GS 2020 server with the same configuration; making reference to the template you used.
    • Created a new project template with multiple languages, that also include references to the same server based TM resources.
    • Used the same version of the ProjectCreator.cs

    Results:

    I performed multiple attempts (100/s) over a period of a few days with various configurations, elapse times, including leaving the automation run over night, thereby fulfilling the requirements of the 12 hour elapse time scenario.  During that time, I was able to reproduce the exception once and quite unexpectedly, straight away after I launched the automation standalone app

    One thing to make note of here is: the automation test-case where the exception was invoked, only occurred once and all successive attempts in the same automation instance were successful.  This means that we could potentially introduce logic to manage failed attempts given the exception type; possibly implemented on the client code as a workaround… initially

    Studio: Investigation

    Continue our investigation to better understand what is causing this exception; tracking nr.: LG-29871

    Workaround

    Until time that we understand better how to reproduce this issue and what is in fact causing it; which might be unrelated to the credential token & 12 hours elapsing.  I recommend the following:

    Given the test-case where I was able to reproduce this exception once and all successive attempts being successful.  You could introduce logic to encapsulate the execution to the project automation to restart the procedure on a failed attempt (or attempts); potentially identifying also the exception type from the content we have seen thus far.
    emoji